perm filename W88.IN[LET,JMC]1 blob
sn#855046 filedate 1988-03-24 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00735 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00085 00002 ∂01-Jan-88 0950 AI.THROOP@R20.UTEXAS.EDU Stuck Tile and Bug Fix
C00095 00003 ∂02-Jan-88 1243 BRINK@Sushi.Stanford.EDU 50 out of 45
C00097 00004 ∂02-Jan-88 1327 BRINK@Sushi.Stanford.EDU The Project
C00102 00005 ∂02-Jan-88 1330 BRINK@Sushi.Stanford.EDU The Report
C00110 00006 ∂02-Jan-88 1331 BRINK@Sushi.Stanford.EDU TRUEP.LISP
C00126 00007 ∂02-Jan-88 1333 BRINK@Sushi.Stanford.EDU MRSFNS.DOC
C00193 00008 ∂02-Jan-88 1335 BRINK@Sushi.Stanford.EDU MATCH.LISP
C00211 00009 ∂02-Jan-88 1352 BRINK@Sushi.Stanford.EDU Delenda
C00213 00010 ∂03-Jan-88 1207 binford@anaconda supercomputing considered harmful
C00214 00011 ∂04-Jan-88 0024 cheriton@pescadero.stanford.edu.stanford.edu Re: supercomputing considered harmful
C00219 00012 ∂04-Jan-88 0830 JMC
C00220 00013 ∂04-Jan-88 0828 TAP public
C00221 00014 ∂04-Jan-88 0900 JMC
C00222 00015 ∂04-Jan-88 0952 CLT tap
C00223 00016 ∂04-Jan-88 1000 JMC
C00224 00017 ∂04-Jan-88 1038 TAP conference call
C00225 00018 ∂04-Jan-88 1300 JMC
C00226 00019 ∂04-Jan-88 1304 croft@safe.stanford.edu russell account
C00230 00020 ∂04-Jan-88 1315 AI.BRANTON@R20.UTEXAS.EDU Keys
C00231 00021 ∂04-Jan-88 1322 AI.BRANTON@R20.UTEXAS.EDU re: Keys
C00232 00022 ∂04-Jan-88 1451 100 (from: tap on TTY76, at TV-141) class
C00233 00023 ∂04-Jan-88 1456 100 (from: tap on TTY101, at TV-141) VTSS meeting
C00234 00024 ∂04-Jan-88 1522 VAL Commonsense and Nonmonotonic Reasoning Seminar
C00236 00025 ∂04-Jan-88 1547 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C00238 00026 ∂04-Jan-88 1537 BRINK@Sushi.Stanford.EDU Off the hook
C00239 00027 ∂04-Jan-88 1549 TAP xerox number
C00240 00028 ∂04-Jan-88 1611 GOTELLI@Score.Stanford.EDU Outside User Computer Account
C00242 00029 ∂04-Jan-88 1658 coraki!pratt@Sun.COM Gurevich
C00244 00030 ∂04-Jan-88 1658 edsel!jlz@labrea.stanford.edu ISO trip to Paris
C00246 00031 ∂04-Jan-88 1832 MATHIS@A.ISI.EDU iso mtg Paris Feb 24-25
C00249 00032 ∂05-Jan-88 0547 enea!LISBET.LiU.SE!M-REINFRANK@uunet.UU.NET NMR-Workshop/Publication
C00252 00033 ∂05-Jan-88 0717 AI.BRANTON@R20.UTEXAS.EDU Keys
C00253 00034 ∂05-Jan-88 0818 GOTELLI@Score.Stanford.EDU re: Outside User Computer Account
C00255 00035 ∂05-Jan-88 0819 TAP VTSS course
C00256 00036 ∂05-Jan-88 0955 SHOHAM@Score.Stanford.EDU ai courses mtg
C00258 00037 ∂05-Jan-88 1000 JMC
C00259 00038 ∂05-Jan-88 1001 GILBERTSON@Score.Stanford.EDU Heating in Rm 356
C00261 00039 ∂05-Jan-88 1005 TAP your car
C00262 00040 ∂05-Jan-88 1007 JUSTESON@Sushi.Stanford.EDU quick meeting
C00264 00041 ∂05-Jan-88 1029 CLT $
C00265 00042 ∂05-Jan-88 1051 TAP alphonse juilland
C00266 00043 ∂05-Jan-88 1138 TAP vtss 160
C00267 00044 ∂05-Jan-88 1143 TAP
C00268 00045 ∂05-Jan-88 1253 JUSTESON@Sushi.Stanford.EDU re: quick meeting
C00270 00046 ∂05-Jan-88 1313 VAL reply to message
C00271 00047 ∂05-Jan-88 1341 JSW Alliant
C00272 00048 ∂05-Jan-88 1817 jcm@navajo.stanford.edu Industrial Lectureship
C00274 00049 ∂05-Jan-88 1817 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [Allen.Newell@C.CS.CMU.EDU: [Allen.Newell@C.CS.CMU.EDU: Re: Schwartz visit?]]
C00289 00050 ∂06-Jan-88 0800 JMC
C00290 00051 ∂06-Jan-88 0900 JMC
C00291 00052 ∂06-Jan-88 0900 JMC
C00292 00053 ∂06-Jan-88 1013 edsel!jlz@labrea.stanford.edu [jlz: ISO trip to Paris]
C00294 00054 ∂06-Jan-88 1102 binford@anaconda welcome back
C00295 00055 ∂06-Jan-88 1106 CLT two things
C00296 00056 ∂06-Jan-88 1113 CLT two things
C00297 00057 ∂06-Jan-88 1734 ME TAP account
C00298 00058 ∂06-Jan-88 1921 Qlisp-mailer new-qlisp available
C00302 00059 ∂06-Jan-88 2116 RPG
C00303 00060 ∂06-Jan-88 2153 RDZ@Score.Stanford.EDU Throop
C00304 00061 ∂06-Jan-88 2308 RFC Prancing Pony Bill
C00306 00062 ∂07-Jan-88 0946 RPG Various topics
C00307 00063 ∂07-Jan-88 1142 LIBRARY@Score.Stanford.EDU tech report overdue
C00309 00064 ∂07-Jan-88 1339 @Score.Stanford.EDU,@RELAY.CS.NET:jamesp@BRANDEIS.CSNET Funds for Workshop proposal
C00319 00065 ∂07-Jan-88 1402 VAL Nonmonotonic Reasoning Seminar: Correction and Reminder
C00321 00066 ∂07-Jan-88 1538 LES Financial review
C00322 00067 ∂07-Jan-88 1813 CLT
C00323 00068 ∂07-Jan-88 1944 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C00325 00069 ∂08-Jan-88 0103 ME failed mail returned
C00327 00070 ∂08-Jan-88 0700 JMC
C00328 00071 ∂08-Jan-88 0743 STEINBERGER@KL.SRI.COM re: quality TV
C00331 00072 ∂08-Jan-88 0917 VAL re: Financial review
C00332 00073 ∂08-Jan-88 1008 CLT
C00333 00074 ∂08-Jan-88 1112 MAYR@Score.Stanford.EDU workshop on pararllel computation
C00336 00075 ∂08-Jan-88 1129 STAGER@Score.Stanford.EDU CS101 text
C00338 00076 ∂08-Jan-88 1236 SHOHAM@Score.Stanford.EDU mtg
C00340 00077 ∂08-Jan-88 1633 STAGER@Score.Stanford.EDU Paul Haley
C00341 00078 ∂08-Jan-88 1650 RPG Qlisp
C00342 00079 ∂08-Jan-88 1658 RPG Meeting
C00343 00080 ∂08-Jan-88 1658 croft@russell.stanford.edu your russell account
C00344 00081 ∂09-Jan-88 0947 RPG Qlisp Situation
C00349 00082 ∂10-Jan-88 1650 ME new login name for Pat Simmons
C00350 00083 ∂10-Jan-88 2010 Qlisp-mailer TAK times
C00353 00084 ∂10-Jan-88 2115 RWW the origin of the name LISP
C00354 00085 ∂11-Jan-88 0045 RWW thanks
C00355 00086 ∂11-Jan-88 0257 LES Post-mortem
C00367 00087 ∂11-Jan-88 0830 STAGER@Score.Stanford.EDU re: Paul Haley
C00368 00088 ∂11-Jan-88 1002 Qlisp-mailer Schedulers
C00371 00089 ∂11-Jan-88 1240 AI.THROOP@R20.UTEXAS.EDU
C00372 00090 ∂11-Jan-88 1423 PHY
C00374 00091 ∂11-Jan-88 1428 helen@psych.Stanford.EDU Re: lunch
C00375 00092 ∂11-Jan-88 1441 Qlisp-mailer Qlisp bug warning
C00377 00093 ∂11-Jan-88 1503 helen@psych.Stanford.EDU re: lunch
C00378 00094 ∂11-Jan-88 1610 BALDWIN@Score.Stanford.EDU free baby gates
C00379 00095 ∂11-Jan-88 1700 @Score.Stanford.EDU:CLANCEY@SUMEX-AIM.Stanford.EDU [Bill Mann <MANN@venera.isi.edu>: [Bill Mann <MANN@VENERA.ISI.EDU>: AAAI -- Workshop proposal: 4th In]]
C00402 00096 ∂11-Jan-88 1804 Qlisp-mailer new qlisp
C00404 00097 ∂12-Jan-88 0910 GOODMAN%uamis@rvax.ccit.arizona.edu slight change of arpanet address
C00406 00098 ∂12-Jan-88 0910 MPS packages from texas
C00407 00099 ∂12-Jan-88 0920 HART@KL.SRI.COM
C00408 00100 ∂12-Jan-88 0958 BALDWIN@Score.Stanford.EDU re: free baby gates
C00409 00101 ∂12-Jan-88 1011 BSCOTT@Score.Stanford.EDU CSD-CF, Qlisp Project
C00410 00102 ∂12-Jan-88 1038 MPS scheduling
C00411 00103 ∂12-Jan-88 1057 Qlisp-mailer meeting
C00412 00104 ∂12-Jan-88 1129 RPG Center
C00423 00105 ∂12-Jan-88 1222 RPG Counter-reaction
C00426 00106 ∂12-Jan-88 1318 VAL
C00427 00107 ∂12-Jan-88 1553 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C00429 00108 ∂12-Jan-88 1619 ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu Lunch
C00431 00109 ∂12-Jan-88 1716 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software Subcommittee
C00436 00110 ∂12-Jan-88 1935 JUSTESON@Sushi.Stanford.EDU letter of reference
C00438 00111 ∂12-Jan-88 2027 Qlisp-mailer new Qlisp constructs
C00443 00112 ∂13-Jan-88 0054 ME bike locker
C00444 00113 ∂13-Jan-88 0139 MATU@Sushi.Stanford.EDU Greeting
C00446 00114 ∂13-Jan-88 0700 JMC
C00447 00115 ∂13-Jan-88 1036 Qlisp-mailer rescheduling meeting
C00448 00116 ∂13-Jan-88 1234 Qlisp-mailer Halstead papers
C00449 00117 ∂13-Jan-88 1355 JUSTESON@Sushi.Stanford.EDU most imminent letter addresses, all for generic positions
C00451 00118 ∂13-Jan-88 2225 rivin@Gang-of-Four.Stanford.EDU biting the bullet
C00456 00119 ∂14-Jan-88 0840 PETTY@RED.RUTGERS.EDU jan-88-techreport-mailing
C00459 00120 ∂14-Jan-88 0850 PHY
C00460 00121 ∂14-Jan-88 1110 VAL Commonsense and nonmonotonic reasoning seminar
C00461 00122 ∂14-Jan-88 1155 LYN@Sierra.Stanford.EDU re: "College Woman" article on AIDS
C00462 00123 ∂14-Jan-88 1204 LYN@Sierra.Stanford.EDU re: "College Woman" article on AIDS
C00464 00124 ∂14-Jan-88 1258 SHOHAM@Score.Stanford.EDU mtg
C00465 00125 ∂14-Jan-88 1314 BJORK@Score.Stanford.EDU Re: modem or multiplexer not working
C00468 00126 ∂14-Jan-88 1359 MPS Room Change
C00469 00127 ∂14-Jan-88 1502 SHOHAM@Score.Stanford.EDU re: mtg
C00470 00128 ∂14-Jan-88 1534 LES Qlisp project continuation
C00472 00129 ∂14-Jan-88 1551 LES re: Qlisp project continuation
C00473 00130 ∂14-Jan-88 1626 LES re: Qlisp project continuation
C00474 00131 con-Jan-88 2258 rivin@Gang-of-Four.Stanford.EDU bullets
C00482 00132 ∂15-Jan-88 0714 squires@vax.darpa.mil ISO Meeting
C00484 00133 ∂15-Jan-88 0800 JMC
C00485 00134 ∂15-Jan-88 1114 kathy@ratliff.cs.utexas.edu UT reimbursement for moving expenses
C00487 00135 ∂15-Jan-88 1445 edsel!arg@labrea.Stanford.EDU bullets - part II
C00491 00136 ∂15-Jan-88 1747 pehoushe@Gang-of-Four.Stanford.EDU other primitive parallel forms?
C00494 00137 ∂15-Jan-88 1809 nilsson@Tenaya.stanford.edu schwartz
C00496 00138 ∂15-Jan-88 1823 latombe@coyote.stanford.edu Re: schwartz
C00497 00139 ∂15-Jan-88 1927 SHOHAM@Score.Stanford.EDU letter from JMC
C00501 00140 ∂15-Jan-88 1928 GENESERETH@Score.Stanford.EDU schwartz
C00503 00141 ∂15-Jan-88 2000 JMC
C00504 00142 ∂15-Jan-88 2026 RPG New Tasks
C00505 00143 ∂16-Jan-88 0947 latombe@coyote.stanford.edu Re: schwartz
C00506 00144 ∂16-Jan-88 1329 binford@anaconda.Stanford.EDU schwartz
C00508 00145 ∂16-Jan-88 2246 Mailer re: nonviolence
C00511 00146 ∂17-Jan-88 1257 Mailer re: nonviolence
C00515 00147 ∂17-Jan-88 1359 cphoenix@portia.Stanford.EDU re: destroying the credibility of famous people
C00517 00148 ∂17-Jan-88 1413 paulf@umunhum.stanford.edu re: MLK Day
C00518 00149 ∂17-Jan-88 1420 cphoenix@portia.Stanford.EDU re: destroying the credibility of famous people
C00520 00150 ∂17-Jan-88 1448 Mailer Re: peace talks
C00523 00151 ∂17-Jan-88 1510 nilsson@Tenaya.stanford.edu cs 520
C00528 00152 ∂17-Jan-88 1721 VAVASIS@Sushi.Stanford.EDU MLK day
C00530 00153 ∂17-Jan-88 1819 rivin@Gang-of-Four.Stanford.EDU bullets - part II
C00532 00154 ∂17-Jan-88 1825 rivin@Gang-of-Four.Stanford.EDU rere...revised proposal
C00541 00155 ∂17-Jan-88 1922 Mailer re: peace talks
C00544 00156 ∂17-Jan-88 1945 Mailer re: peace talks
C00547 00157 ∂18-Jan-88 0902 GOODMAN%uamis@rvax.ccit.arizona.edu How are you all doing??
C00549 00158 ∂18-Jan-88 1117 T.TECHNO@MACBETH.STANFORD.EDU Hello. I don't mean to bother you, but I was one of the students at
C00551 00159 ∂18-Jan-88 1513 @Score.Stanford.EDU:AI.THROOP@R20.UTEXAS.EDU Making Macro Moves
C00556 00160 ∂18-Jan-88 1518 bill@isl.Stanford.EDU nuclear tests
C00557 00161 ∂18-Jan-88 1630 jcm@navajo.stanford.edu baby gates
C00558 00162 ∂18-Jan-88 1837 Qlisp-mailer some agenda items for Wednesday's meeting
C00560 00163 ∂18-Jan-88 1852 JSW
C00561 00164 ∂18-Jan-88 1912 Mailer re: peace talks
C00563 00165 ∂18-Jan-88 1948 Qlisp-mailer place of meeting
C00564 00166 ∂18-Jan-88 2005 Mailer re: peace talks
C00568 00167 ∂18-Jan-88 2155 JSW Emacs and WAITS characters
C00570 00168 ∂19-Jan-88 0750 PHY
C00571 00169 ∂19-Jan-88 0913 JSW Displaying extended characters
C00573 00170 ∂19-Jan-88 1006 VAL Ed Brink
C00576 00171 ∂19-Jan-88 1233 rivin@Gang-of-Four.Stanford.EDU re↑17vised proposal
C00586 00172 ∂19-Jan-88 1245 Qlisp-mailer meeting agenda,etc
C00588 00173 ∂19-Jan-88 1439 AIR qlisp, gcd
C00589 00174 ∂19-Jan-88 1601 MPS darpa
C00590 00175 ∂19-Jan-88 1614 BEDIT@Score.Stanford.EDU Summary of November computer charges.
C00593 00176 ∂19-Jan-88 1639 MPS phone call
C00594 00177 ∂19-Jan-88 2054 Mailer re: peace talks
C00598 00178 ∂19-Jan-88 2108 Mailer re: peace talks
C00604 00179 ∂19-Jan-88 2313 mcvax!litp!queinnec@uunet.UU.NET IWoLES proceedings
C00607 00180 ∂19-Jan-88 2359 Mailer The Narrow Interpretation Of The Constitution
C00609 00181 ∂20-Jan-88 0157 Mailer re: peace talks
C00615 00182 ∂20-Jan-88 0907 MPS lunch
C00617 00183 ∂20-Jan-88 1059 BSCOTT@Score.Stanford.EDU [PUCCI@A.ISI.EDU: Re: [Betty Scott <BSCOTT@SCORE.STANFORD.EDU>: N00039-84-C-0211 Budget Justification for Extension]]
C00621 00184 ∂20-Jan-88 1411 PHY
C00622 00185 ∂20-Jan-88 1458 Qlisp-mailer qlisp documentation
C00624 00186 ∂20-Jan-88 1609 VAL Commonsense and Nonmonotonic Reasoning Seminar
C00627 00187 ∂20-Jan-88 1635 cheriton@Pescadero.stanford.edu Fac. Senate and the Decline of Western Culture
C00629 00188 ∂20-Jan-88 2313 cheriton@Pescadero.stanford.edu re: Fac. Senate and the Decline of Western Culture
C00630 00189 ∂21-Jan-88 0949 MPS Insight Magazine
C00631 00190 ∂21-Jan-88 1043 LOGMTC-mailer Logic-of-Programs Seminar
C00633 00191 ∂21-Jan-88 1140 helen@psych.Stanford.EDU Hi there
C00634 00192 ∂21-Jan-88 1628 JSW GNU Emacs
C00635 00193 ∂21-Jan-88 2041 JSW Some benchmark results
C00640 00194 ∂21-Jan-88 2258 paulf@umunhum.stanford.edu Re: industrial lecturers
C00641 00195 ∂22-Jan-88 0248 Mailer Re: Bimonthly
C00643 00196 ∂22-Jan-88 0700 JMC
C00644 00197 ∂22-Jan-88 0900 JMC
C00645 00198 ∂22-Jan-88 0923 paulf@umunhum.stanford.edu re: industrial lecturers
C00647 00199 ∂22-Jan-88 0936 ULLMAN@Score.Stanford.EDU Re: industrial lecturers
C00649 00200 ∂22-Jan-88 1010 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: industrial lecturers
C00651 00201 ∂22-Jan-88 1027 ULLMAN@Score.Stanford.EDU re: industrial lecturers
C00652 00202 ∂22-Jan-88 1031 @Score.Stanford.EDU:ZM@SAIL.Stanford.EDU Re: industrial lecturers
C00654 00203 ∂22-Jan-88 1058 helen@psych.Stanford.EDU Most enjoyable
C00656 00204 ∂22-Jan-88 1153 VAL
C00657 00205 ∂22-Jan-88 1227 helen@psych.Stanford.EDU re: Most enjoyable
C00658 00206 ∂22-Jan-88 1209 VAL re: reply to message
C00659 00207 ∂22-Jan-88 1236 CLT kronos
C00660 00208 ∂22-Jan-88 1252 FLAVIU@IBM.COM
C00671 00209 ∂22-Jan-88 1412 ULLMAN@Score.Stanford.EDU Jim Gray
C00673 00210 ∂22-Jan-88 1647 Mailer Re: In defense of the British
C00680 00211 ∂22-Jan-88 1722 jlh@vsop.stanford.edu re: Jim Gray
C00682 00212 ∂22-Jan-88 1806 edsel!arg@labrea.Stanford.EDU Qlisp quarterly report
C00690 00213 ∂22-Jan-88 1841 SINGH@Sierra.Stanford.EDU BEYOND Gandhi and the British
C00693 00214 ∂22-Jan-88 2003 edsel!arg@labrea.Stanford.EDU process overhead in QEXP
C00695 00215 ∂22-Jan-88 2031 RPG Paris
C00696 00216 ∂22-Jan-88 2052 JSW Eagle maintenance
C00698 00217 ∂22-Jan-88 2307 rivin@Gang-of-Four.Stanford.EDU Re: Qlisp quarterly report
C00699 00218 ∂23-Jan-88 0700 JMC
C00700 00219 ∂23-Jan-88 1026 nilsson@Tenaya.stanford.edu Jim Gray
C00702 00220 ∂23-Jan-88 1031 hilbert@alan.stanford.edu re: CSLI Internships
C00703 00221 ∂23-Jan-88 1309 edsel!jlz@labrea.Stanford.EDU Paris hotel
C00705 00222 ∂23-Jan-88 1412 REGES@Score.Stanford.EDU Re: Jim Gray
C00707 00223 ∂23-Jan-88 1418 nilsson@Tenaya.stanford.edu Feb 17 visit
C00715 00224 ∂23-Jan-88 1438 T.TECHNO@MACBETH.STANFORD.EDU Hello...
C00716 00225 ∂23-Jan-88 1643 SHOHAM@Score.Stanford.EDU
C00717 00226 ∂24-Jan-88 0834 T.TECHNO@MACBETH.STANFORD.EDU re: Hello...
C00719 00227 ∂24-Jan-88 1234 MATHIS@A.ISI.EDU Paris reservations
C00722 00228 ∂24-Jan-88 1401 Mailer 1. Self-defense [Was Re: In defense of the British]
C00732 00229 ∂24-Jan-88 1618 L.LILITH@OTHELLO.STANFORD.EDU re: The British and the subhumans
C00735 00230 ∂24-Jan-88 1647 L.LILITH@OTHELLO.STANFORD.EDU Re: In defense of the British
C00738 00231 ∂24-Jan-88 1706 Mailer Thanks to Prof. McCarthy [Was Re: self defense and apology]
C00741 00232 ∂25-Jan-88 0700 JMC
C00742 00233 ∂25-Jan-88 0700 JMC
C00743 00234 ∂25-Jan-88 0759 ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu surprise present
C00745 00235 ∂25-Jan-88 1039 yao.pa@Xerox.COM Industrial Lectureship
C00747 00236 ∂25-Jan-88 1127 yao.pa@Xerox.COM Re: Industrial Lectureship
C00749 00237 ∂25-Jan-88 1138 JUSTESON@Sushi.Stanford.EDU letter for IBM Watson - Speech Recognition - Feb. 5 interview
C00751 00238 ∂25-Jan-88 1201 CRISPIN@SUMEX-AIM.Stanford.EDU Tibet
C00755 00239 ∂25-Jan-88 1222 rivin@Gang-of-Four.Stanford.EDU I am here
C00757 00240 ∂25-Jan-88 1224 simpson@vax.darpa.mil AI and Formal Reasoning Proposal
C00760 00241 ∂25-Jan-88 1503 Qlisp-mailer Next meeting
C00761 00242 ∂25-Jan-88 1657 ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu RE: re: surprise present
C00763 00243 ∂25-Jan-88 2226 helen@psych.Stanford.EDU Re: starting earlier
C00764 00244 ∂26-Jan-88 0700 JMC
C00765 00245 ∂26-Jan-88 1113 BSCOTT@Score.Stanford.EDU Letter to Col. Simpson
C00766 00246 ∂26-Jan-88 1240 Mailer failed mail returned
C00767 00247 ∂26-Jan-88 1303 rivin@Gang-of-Four.Stanford.EDU [edsel!jlz@labrea.Stanford.EDU: Next meeting]
C00769 00248 ∂26-Jan-88 1309 JSW Symbolics Multiprocessor
C00770 00249 ∂26-Jan-88 1320 JSW
C00771 00250 ∂26-Jan-88 1459 APPELT@WARBUCKS.AI.SRI.COM Backing up LISPMs
C00775 00251 ∂26-Jan-88 1533 SLOAN@Score.Stanford.EDU Visiting Research Associates
C00777 00252 ∂26-Jan-88 1603 JSW Disk maintenance
C00780 00253 ∂26-Jan-88 1710 CS.PURVIS@R20.UTEXAS.EDU Hello
C00782 00254 ∂26-Jan-88 1723 JSW Symbolics multiprocessor presentation
C00783 00255 ∂26-Jan-88 1800 JMC
C00784 00256 ∂26-Jan-88 1807 CS.PURVIS@R20.UTEXAS.EDU Hello
C00785 00257 ∂26-Jan-88 2030 Qlisp-mailer new-qlisp image
C00787 00258 ∂27-Jan-88 0902 RICHARDSON@Score.Stanford.EDU Meeting at Robotics Lab for 2/3/88
C00789 00259 ∂27-Jan-88 0909 MPS meeting
C00790 00260 ∂27-Jan-88 0930 AI.PETRIE@MCC.COM Your Institution
C00792 00261 ∂27-Jan-88 1159 Mailer failed mail returned
C00799 00262 ∂27-Jan-88 1322 AIR QLISP & GCD
C00819 00263 ∂27-Jan-88 1518 MPS expenses
C00820 00264 ∂27-Jan-88 1727 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software Subcommittee Reminder
C00829 00265 ∂27-Jan-88 1830 JK
C00830 00266 ∂27-Jan-88 1833 NSH
C00831 00267 ∂27-Jan-88 2142 RPG DARPA and Qlisp
C00834 00268 ∂27-Jan-88 2155 rivin@Gang-of-Four.Stanford.EDU DARPA and Qlisp
C00836 00269 ∂28-Jan-88 0851 HART@KL.SRI.COM Re: mailing address
C00837 00270 ∂28-Jan-88 0900 JMC
C00838 00271 ∂28-Jan-88 0916 MPS nomination
C00839 00272 ∂28-Jan-88 0942 ullman@navajo.stanford.edu action item?
C00841 00273 ∂28-Jan-88 1003 chapman@russell.stanford.edu Andrei Ershov
C00843 00274 ∂28-Jan-88 1011 MPS nsf
C00844 00275 ∂28-Jan-88 1119 chapman@russell.stanford.edu re: Andrei Ershov
C00852 00276 ∂28-Jan-88 1129 VAL Ed Brink
C00855 00277 ∂28-Jan-88 1122 coraki!pratt@Sun.COM Re: action item?
C00857 00278 ∂28-Jan-88 1207 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C00859 00279 ∂28-Jan-88 1240 Qlisp-mailer Parallelizing Functional Programs with Qlisp
C00865 00280 ∂28-Jan-88 1329 ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu re: Lunch
C00867 00281 ∂28-Jan-88 1416 simpson@vax.darpa.mil Re: Feb 17 visit
C00870 00282 ∂28-Jan-88 1621 Qlisp-mailer GNU Emacs customizations for Qlisp
C00872 00283 ∂28-Jan-88 1720 simpson@vax.darpa.mil re: AI and Formal Reasoning Proposal
C00874 00284 ∂28-Jan-88 1815 JK books
C00875 00285 ∂28-Jan-88 1843 Qlisp-mailer fib
C00878 00286 ∂28-Jan-88 1908 helen@psych.Stanford.EDU Hi there and correction
C00880 00287 ∂28-Jan-88 2033 edsel!arg@labrea.Stanford.EDU proposed additional Qlisp tasks
C00890 00288 ∂28-Jan-88 2134 JSW Re: QLISP & GCD
C00894 00289 ∂29-Jan-88 0901 GOODMAN%uamis@rvax.ccit.arizona.edu copy request
C00896 00290 ∂29-Jan-88 0903 RPG McCarthy goes to Paris
C00898 00291 ∂29-Jan-88 0911 RICHARDSON@Score.Stanford.EDU Visiting Committee breakfast on 2/3/88
C00900 00292 ∂29-Jan-88 0934 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C00903 00293 ∂29-Jan-88 1050 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu copy of work send to John Ousterhout due today
C00944 00294 ∂29-Jan-88 1243 CLT nsf
C00945 00295 ∂29-Jan-88 1252 GINSBERG@Sushi.Stanford.EDU read a play on Sunday night?
C00946 00296 ∂29-Jan-88 1533 KEARNS@CS.COLUMBIA.EDU chance meeting
C00948 00297 ∂29-Jan-88 1715 CWeissman.BSPO@DOCKMASTER.ARPA sOFTWARE COMMITTEE
C00967 00298 ∂30-Jan-88 1140 mcvax!litp!queinnec@uunet.UU.NET IWoLES (copyright release)
C00971 00299 ∂30-Jan-88 1147 mcvax!litp!queinnec@uunet.UU.NET IWoLES
C00973 00300 ∂30-Jan-88 1633 GINSBERG@Sushi.Stanford.EDU play tomorrow?
C00974 00301 ∂30-Jan-88 1740 RPG Wednesday
C00975 00302 ∂30-Jan-88 1830 ILAN@Score.Stanford.EDU Apparently Berliner doesn't like flames
C00978 00303 ∂31-Jan-88 0751 RPG
C00979 00304 ∂31-Jan-88 1149 JSW Gang-of-Four
C00980 00305 ∂31-Jan-88 1207 edsel!jlz@labrea.Stanford.EDU Paris hotel
C00982 00306 ∂31-Jan-88 1449 JSW Reminder: Symbolics Multiprocessor meeting
C00983 00307 ∂31-Jan-88 1742 CLT Gang-of-Four
C00984 00308 ∂01-Feb-88 0815 RPG Arpa Visit
C00985 00309 ∂01-Feb-88 0900 JMC
C00986 00310 ∂01-Feb-88 1042 SINGH@Sierra.Stanford.EDU re: Passing of `Frontier Gandhi'
C00988 00311 ∂01-Feb-88 1345 helen@psych.Stanford.EDU MY generation
C00990 00312 ∂01-Feb-88 1416 helen@psych.Stanford.EDU re: MY generation
C00991 00313 ∂01-Feb-88 1615 edsel!arg@labrea.Stanford.EDU Qlisp DARPA meeting Wednesday night
C00993 00314 ∂01-Feb-88 1639 RICHARDSON@Score.Stanford.EDU Visiting Committee Agenda
C00995 00315 ∂01-Feb-88 1725 Qlisp-mailer meeting
C00997 00316 ∂01-Feb-88 2049 rivin@Gang-of-Four.Stanford.EDU meeting at LUCID (on wednesday)
C00998 00317 ∂01-Feb-88 2233 RDZ@Score.Stanford.EDU [David Chapman <ZVONA@AI.AI.MIT.EDU>: Segreyev]
C01002 00318 ∂01-Feb-88 2243 rivin@Gang-of-Four.Stanford.EDU extension
C01003 00319 ∂02-Feb-88 0052 RFC Prancing Pony Bill
C01005 00320 ∂02-Feb-88 0902 DEK
C01007 00321 ∂02-Feb-88 0922 MPS Sequent Computer
C01008 00322 ∂02-Feb-88 0932 BRINK@Sushi.Stanford.EDU Meeting
C01009 00323 ∂02-Feb-88 1045 DEK memo to Nils
C01010 00324 ∂02-Feb-88 1117 GINSBERG@Sushi.Stanford.EDU Schwartz visit
C01013 00325 ∂02-Feb-88 1412 celniker@cadlab2.MIT.EDU
C01016 00326 ∂02-Feb-88 1431 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01018 00327 ∂02-Feb-88 1507 JSW Symbolics Multiprocessor
C01019 00328 ∂02-Feb-88 1533 MPS phone
C01020 00329 ∂02-Feb-88 1644 RICE@SUMEX-AIM.Stanford.EDU re: A big thankyou...
C01022 00330 ∂02-Feb-88 1701 VAL nonhyphenating "non"
C01023 00331 ∂02-Feb-88 1854 VAL
C01024 00332 ∂02-Feb-88 2025 VAL draft introduction
C01025 00333 ∂03-Feb-88 1054 ILAN@Score.Stanford.EDU [Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>: [MLB@WHITE.SWW.Symbolics.COM: [ILAN@Score.Stanford.EDU: Re: questions o
C01029 00334 ∂03-Feb-88 1206 Qlisp-mailer Carolyn's questions about fib
C01033 00335 ∂03-Feb-88 1333 Qlisp-mailer factors of 100-1000
C01034 00336 ∂03-Feb-88 1343 Mailer re: More mathematical style
C01036 00337 ∂03-Feb-88 1545 PHY vita
C01037 00338 ∂03-Feb-88 1655 Mailer re: United Nations & Israel
C01041 00339 ∂03-Feb-88 1940 AI.BLEDSOE@R20.UTEXAS.EDU Re: Robert Halstead
C01043 00340 ∂03-Feb-88 2210 JUSTESON@Sushi.Stanford.EDU Tasaday talk Thursday Feb. 4, noon
C01044 00341 ∂04-Feb-88 0538 rms@wheaties.ai.mit.edu Boesch
C01045 00342 ∂04-Feb-88 0800 JMC
C01047 00343 ∂04-Feb-88 1036 P.PROMETHEUS@MACBETH.STANFORD.EDU honors project/csli internship
C01052 00344 ∂04-Feb-88 1126 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C01054 00345 ∂04-Feb-88 1215 DEK Monday the 15th
C01055 00346 ∂04-Feb-88 1248 BEDIT@Score.Stanford.EDU Summary of December computer charges.
C01058 00347 ∂04-Feb-88 1253 jcm@navajo.stanford.edu Proposal for new course.
C01060 00348 ∂04-Feb-88 1358 pratt@chehalis Re: Proposal for new course.
C01062 00349 ∂04-Feb-88 1429 DEK
C01064 00350 ∂05-Feb-88 0900 JMC
C01065 00351 ∂05-Feb-88 0931 MPS Keynote Speech
C01066 00352 ∂05-Feb-88 0933 MPS phone number
C01067 00353 ∂05-Feb-88 0948 Qlisp-mailer LIFO and FIFO queues, single and multiple queues, fib, qempty
C01074 00354 ∂05-Feb-88 0948 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C01076 00355 ∂05-Feb-88 1023 MPS Sequent Computer
C01077 00356 ∂05-Feb-88 1159 pratt%jah@Sun.COM Re: New Course: CS 258
C01079 00357 ∂05-Feb-88 1304 forbus@p.cs.uiuc.edu QPW-88: CALL FOR PAPERS
C01087 00358 ∂05-Feb-88 1424 Qlisp-mailer Number of spawns with qemptyp
C01089 00359 ∂05-Feb-88 1503 M.MAURYCE@MACBETH.STANFORD.EDU An Interview with U
C01092 00360 ∂05-Feb-88 1503 Qlisp-mailer Current lock operations are expensive.
C01096 00361 ∂05-Feb-88 1609 DEK gosper visit
C01097 00362 ∂05-Feb-88 1646 GINSBERG@Sushi.Stanford.EDU yet *another* way to waste some time?
C01100 00363 ∂05-Feb-88 1717 jcm@navajo.stanford.edu Re: Proposal for new course.
C01104 00364 ∂05-Feb-88 2156 Qlisp-mailer timing Qlisp programs
C01107 00365 ∂06-Feb-88 1240 jbn@glacier.stanford.edu A third path to artificial intelligence
C01111 00366 ∂06-Feb-88 1551 mcvax!inria.inria.fr!queinnec@uunet.UU.NET re: IWoLES
C01113 00367 ∂07-Feb-88 0957 sdcsvax!hp-sdd!sceard!mrm@rutgers.edu Re: two extreme approaches to AI
C01115 00368 ∂07-Feb-88 1326 VAL
C01116 00369 ∂07-Feb-88 1333 nilsson@Tenaya.stanford.edu your memo of 2/2/88
C01118 00370 ∂07-Feb-88 1347 VAL
C01119 00371 ∂07-Feb-88 1458 VAL Book
C01121 00372 ∂07-Feb-88 1534 VAL re: Book
C01122 00373 ∂07-Feb-88 1705 Qlisp-mailer Re: timing Qlisp programs
C01126 00374 ∂07-Feb-88 1730 jlh@vsop.stanford.edu Re: Bert Halstead
C01127 00375 ∂07-Feb-88 1918 Qlisp-mailer timing Qlisp programs
C01140 00376 ∂08-Feb-88 0343 rivin@Gang-of-Four.Stanford.EDU QLISP budget draft
C01147 00377 ∂08-Feb-88 0942 CLT budget
C01149 00378 ∂08-Feb-88 1242 LIBRARY@Score.Stanford.EDU tech report overdue
C01151 00379 ∂08-Feb-88 1314 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software subcommittee report
C01153 00380 ∂08-Feb-88 1409 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU re: Software subcommittee report
C01154 00381 ∂08-Feb-88 1645 STAGER@Score.Stanford.EDU Re: industrial lecturers
C01155 00382 ∂08-Feb-88 1658 LES re: QLISP budget draft
C01157 00383 ∂08-Feb-88 2045 ZVONA%OZ.AI.MIT.EDU@AI.AI.MIT.EDU
C01166 00384 ∂09-Feb-88 0220 rivin@Gang-of-Four.Stanford.EDU QLISP budget draft
C01172 00385 ∂09-Feb-88 1007 MPS Professor Lanzara
C01173 00386 ∂09-Feb-88 1030 VAL re: intro
C01174 00387 ∂09-Feb-88 1037 VAL seminar
C01175 00388 ∂09-Feb-88 1240 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: QLISP budget draft ]
C01179 00389 ∂09-Feb-88 1242 Qlisp-mailer meeting
C01180 00390 ∂09-Feb-88 1326 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01182 00391 ∂09-Feb-88 1332 VAL Tallinn
C01186 00392 ∂09-Feb-88 1503 helen@psych.Stanford.EDU Re: postpone lunch
C01187 00393 ∂09-Feb-88 1528 jcm@navajo.stanford.edu CS 258
C01189 00394 ∂09-Feb-88 1540 helen@psych.Stanford.EDU re: postpone lunch
C01190 00395 ∂09-Feb-88 1654 BERGMAN@Score.Stanford.EDU new NSF grant
C01192 00396 ∂09-Feb-88 1857 Qlisp-mailer global variables in Qlisp (was: timing Qlisp programs)
C01194 00397 ∂09-Feb-88 1930 Qlisp-mailer Re: global variables in Qlisp (was: timing Qlisp programs)
C01196 00398 ∂10-Feb-88 0108 RDZ@Score.Stanford.EDU Party for John McCarthy
C01199 00399 ∂10-Feb-88 0944 Mailer re: Yet another flight to EastRidge Field...
C01200 00400 ∂10-Feb-88 1420 paulf@umunhum.stanford.edu Charlie Bass
C01201 00401 ∂10-Feb-88 1932 Qlisp-mailer global variables in Qlisp
C01203 00402 ∂10-Feb-88 1959 Qlisp-mailer new-qlisp
C01206 00403 ∂10-Feb-88 2000 JMC
C01207 00404 ∂10-Feb-88 2251 @Score.Stanford.EDU,@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU,@MC.LCS.MIT.EDU:lusk@anl-mcs.ARPA CADE-9 registration info and preliminary schedule
C01234 00405 ∂11-Feb-88 0908 MPS Omni Magazine
C01235 00406 ∂11-Feb-88 0944 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C01237 00407 ∂11-Feb-88 1119 VAL phil.tex[ess,jmc]
C01238 00408 ∂11-Feb-88 1504 RPG Point of Fact
C01239 00409 ∂11-Feb-88 1540 Mailer re: James Bond question
C01240 00410 ∂11-Feb-88 1617 VAL The 1980 circ'n paper
C01241 00411 ∂12-Feb-88 0039 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C01243 00412 ∂12-Feb-88 0133 rivin@Gang-of-Four.Stanford.EDU Is that what Boesh wants, do you think?
C01255 00413 ∂12-Feb-88 0250 rivin@Gang-of-Four.Stanford.EDU next week
C01257 00414 ∂12-Feb-88 1134 VAL two puzzles
C01258 00415 ∂12-Feb-88 1151 PMACLIN%UTMEM1.BITNET@forsythe.stanford.edu your Daedelus paper
C01260 00416 ∂12-Feb-88 1351 P.PROMETHEUS@HAMLET.STANFORD.EDU honors project/CSLI internship
C01261 00417 ∂12-Feb-88 1403 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
C01264 00418 ∂12-Feb-88 1409 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
C01266 00419 ∂12-Feb-88 1417 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
C01267 00420 ∂12-Feb-88 1600 L.LARSSON@MACBETH.STANFORD.EDU re: honors project/CSLI internship
C01268 00421 ∂12-Feb-88 1615 JSW Alliant & Symbolics
C01270 00422 ∂13-Feb-88 1218 helen@psych.Stanford.EDU Have you forgotten something?
C01272 00423 ∂13-Feb-88 1228 helen@psych.Stanford.EDU Oops, sorry
C01273 00424 ∂13-Feb-88 1655 helen@psych.Stanford.EDU Party Info!
C01275 00425 ∂13-Feb-88 1843 helen@psych.Stanford.EDU Tonight: plans
C01277 00426 ∂14-Feb-88 1119 mcvax!inria.inria.fr!queinnec@uunet.UU.NET re: IWoLES
C01279 00427 ∂14-Feb-88 1158 rivin@Gang-of-Four.Stanford.EDU Alliant & Symbolics
C01283 00428 ∂14-Feb-88 1317 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: QLISP budget draft ]
C01288 00429 ∂14-Feb-88 1329 rivin@Gang-of-Four.Stanford.EDU mini-budget
C01294 00430 ∂14-Feb-88 1408 BRINK@Sushi.Stanford.EDU Missed your talk
C01295 00431 ∂14-Feb-88 2026 helen@psych.Stanford.EDU Re: lunch?
C01296 00432 ∂15-Feb-88 0900 JMC
C01297 00433 ∂15-Feb-88 0929 hearn%hilbert@rand-unix.ARPA Re: Software Subcommittee Reminder
C01309 00434 ∂15-Feb-88 0931 hearn%hilbert@rand-unix.ARPA DES Software Distribution Correspondence
C01342 00435 ∂15-Feb-88 0930 DEK ooops
C01343 00436 ∂15-Feb-88 1148 rivin@Gang-of-Four.Stanford.EDU budget
C01344 00437 ∂15-Feb-88 1302 rivin@Gang-of-Four.Stanford.EDU short term proposal
C01359 00438 ∂15-Feb-88 1314 yao.pa@Xerox.COM Re: Industrial Lectureship
C01361 00439 ∂15-Feb-88 1450 VAL CBCL
C01362 00440 ∂15-Feb-88 1556 Qlisp-mailer change to release-lock routine
C01365 00441 ∂15-Feb-88 1654 GENESERETH@Score.Stanford.EDU tentative darpa schedule
C01369 00442 ∂15-Feb-88 2304 enea!LISBET.LiU.SE!M-REINFRANK@uunet.UU.NET nmr-workshop
C01373 00443 ∂16-Feb-88 0041 Mailer Airline Deregulation [was re: Inc. letter for Boobists to consider]
C01376 00444 ∂16-Feb-88 0917 BJORK@Score.Stanford.EDU Link
C01377 00445 ∂16-Feb-88 1012 CLT
C01378 00446 ∂16-Feb-88 1025 hayes.pa@Xerox.COM Munich
C01379 00447 ∂16-Feb-88 1242 MPS LA Trip
C01380 00448 ∂16-Feb-88 1244 MPS Paris Trip
C01381 00449 ∂16-Feb-88 1303 RPG Paris
C01382 00450 ∂16-Feb-88 1449 RPG Common Prototyping Language
C01387 00451 ∂16-Feb-88 1528 nilsson@Tenaya.stanford.edu Common Prototyping Language
C01389 00452 ∂16-Feb-88 1526 MPS Mileage
C01390 00453 ∂16-Feb-88 1532 MPS address
C01391 00454 ∂16-Feb-88 1605 BJORK@Score.Stanford.EDU Re: terminal not working
C01392 00455 ∂16-Feb-88 1613 RPG CPL
C01394 00456 ∂16-Feb-88 1636 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01396 00457 ∂16-Feb-88 1658 BJORK@Score.Stanford.EDU Link
C01398 00458 ∂16-Feb-88 2204 Qlisp-mailer meeting
C01399 00459 ∂17-Feb-88 0900 JMC
C01400 00460 ∂17-Feb-88 0955 GENESERETH@Score.Stanford.EDU possible final schedule
C01404 00461 ∂17-Feb-88 0955 GENESERETH@Score.Stanford.EDU LUNCH EARLIER
C01405 00462 ∂17-Feb-88 1016 SHOHAM@Score.Stanford.EDU the schwartz visit
C01407 00463 ∂17-Feb-88 1124 helen@psych.Stanford.EDU Question/advice
C01409 00464 ∂17-Feb-88 1150 MPS phone calls
C01410 00465 ∂17-Feb-88 1159 @ai.toronto.edu:hector@ephemeral.ai.toronto.edu Its out, by gar!!
C01413 00466 ∂17-Feb-88 1400 Qlisp-mailer new-qlisp
C01415 00467 ∂17-Feb-88 1620 RDZ@Score.Stanford.EDU Party details
C01417 00468 ∂17-Feb-88 1751 helen@psych.Stanford.EDU Re: advice
C01418 00469 ∂17-Feb-88 2114 helen@psych.Stanford.EDU Re: alternate plan
C01419 00470 ∂18-Feb-88 0816 nilsson@Tenaya.stanford.edu Schwartz visit
C01423 00471 ∂18-Feb-88 0900 JMC
C01424 00472 ∂18-Feb-88 0900 JMC
C01425 00473 ∂18-Feb-88 1045 RICHARDSON@Score.Stanford.EDU Lunch
C01426 00474 ∂18-Feb-88 1130 GINSBERG@Sushi.Stanford.EDU informal lunches on Thursdays
C01428 00475 ∂18-Feb-88 1234 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C01430 00476 ∂18-Feb-88 1403 VAL correction
C01431 00477 ∂18-Feb-88 1418 VAL book
C01432 00478 ∂18-Feb-88 1442 BSCOTT@Score.Stanford.EDU VTSS Honorarium
C01433 00479 ∂18-Feb-88 1649 Qlisp-mailer Qlisp language issues
C01436 00480 ∂18-Feb-88 1836 VAL CS326
C01437 00481 ∂18-Feb-88 1839 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C01439 00482 ∂19-Feb-88 0700 JMC
C01440 00483 ∂19-Feb-88 0749 helen@psych.Stanford.EDU
C01441 00484 ∂19-Feb-88 0910 Mailer Re: Air Line Ticket Problem
C01442 00485 ∂19-Feb-88 0930 JMC
C01443 00486 ∂19-Feb-88 0955 CLT qlisp
C01444 00487 ∂19-Feb-88 1029 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: short term proposal ]
C01456 00488 ∂19-Feb-88 1119 Qlisp-mailer QAND, QOR
C01458 00489 ∂19-Feb-88 1206 VAL book
C01459 00490 ∂19-Feb-88 1219 Qlisp-mailer EAGER and FUTURE
C01463 00491 ∂19-Feb-88 1500 Qlisp-mailer QAND, QOR
C01467 00492 ∂19-Feb-88 1605 MPS
C01468 00493 ∂19-Feb-88 1607 CLT [boesch@vax.darpa.mil: Re: short term proposal ]
C01469 00494 ∂20-Feb-88 0905 REGES@Score.Stanford.EDU CS101
C01471 00495 ∂20-Feb-88 1026 REGES@Score.Stanford.EDU re: CS101
C01474 00496 ∂20-Feb-88 1034 Qlisp-mailer Conference announcement
C01482 00497 ∂20-Feb-88 1120 helen@psych.Stanford.EDU Running a little late
C01483 00498 ∂21-Feb-88 1021 nilsson@Tenaya.stanford.edu Gordon Bell
C01485 00499 ∂21-Feb-88 1400 scherlis@vax.darpa.mil FINANCIAL AND TECHNICAL REPORTS
C01495 00500 ∂21-Feb-88 1618 VAL Plekhanov
C01496 00501 ∂22-Feb-88 0937 SLOAN@Score.Stanford.EDU Pat Simmons
C01497 00502 ∂22-Feb-88 0950 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Draft software report
C01557 00503 ∂22-Feb-88 1003 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [Nancy/Flora <COMMUNICATIONS@SUMEX-AIM.Stanford.EDU>: SIGLunch Announcement]
C01564 00504 ∂22-Feb-88 1230 @ai.toronto.edu:hector@ephemeral.ai.toronto.edu Computational Intelligence
C01568 00505 ∂22-Feb-88 1441 CLT calendar event
C01569 00506 ∂22-Feb-88 1602 hearn%hilbert@rand-unix.ARPA Re: Draft software report
C01594 00507 ∂23-Feb-88 1351 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01596 00508 ∂23-Feb-88 1349 SJG reminder: Formfeed on Thursday
C01597 00509 ∂23-Feb-88 1359 CLT
C01598 00510 ∂23-Feb-88 1524 yuly@csv.rpi.edu
C01600 00511 ∂23-Feb-88 1544 helen@psych.Stanford.EDU Dinner Thursday, a problem I fear
C01602 00512 ∂23-Feb-88 1726 VAL book
C01603 00513 ∂23-Feb-88 1925 good@cli.com FINANCIAL AND TECHNICAL REPORTS
C01605 00514 ∂23-Feb-88 1928 gerry%eusip.edinburgh.ac.uk@nss.cs.ucl.ac.uk AAAI
C01608 00515 ∂24-Feb-88 0648 scherlis@vax.darpa.mil sw-pi
C01610 00516 ∂24-Feb-88 1324 CLT Financial info -- qlisp
C01612 00517 ∂24-Feb-88 1342 justeson@Portia.STANFORD.EDU letters of reference 5 requests
C01613 00518 ∂24-Feb-88 2033 VAL book
C01615 00519 ∂25-Feb-88 0000 JMC
C01616 00520 ∂25-Feb-88 0901 Qlisp-mailer Interchange with TAK: TAO and more
C01675 00521 ∂25-Feb-88 1248 @po2.andrew.cmu.edu:lb0q+@andrew.cmu.edu Workshop sponsored by AAAI?
C01680 00522 ∂25-Feb-88 1415 Mailer failed mail returned
C01681 00523 ∂25-Feb-88 1425 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C01683 00524 ∂25-Feb-88 1429 Qlisp-mailer new-qlisp
C01685 00525 ∂25-Feb-88 1451 STAGER@Score.Stanford.EDU 1988/89 Courses and Degrees
C01687 00526 ∂25-Feb-88 1610 BEDIT@Score.Stanford.EDU Summary of January computer charges.
C01690 00527 ∂25-Feb-88 1808 hayes.pa@Xerox.COM Re: Summary of January computer charges.
C01693 00528 ∂25-Feb-88 1812 rivin@Gang-of-Four.Stanford.EDU letter of interest to symbolics
C01698 00529 ∂25-Feb-88 2102 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C01700 00530 ∂26-Feb-88 1126 nilsson@Tenaya.stanford.edu [APPELT@SRI-WARBUCKS.ARPA: [Margaret Olender <olender@malibu.ai.sri.com>: UPCOMING TALK
C01706 00531 ∂26-Feb-88 1321 helen@psych.Stanford.EDU Re: dinner
C01707 00532 ∂26-Feb-88 1723 Qlisp-mailer meeting
C01708 00533 ∂26-Feb-88 1737 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Reminder
C01710 00534 ∂26-Feb-88 1847 binford@Boa-Constrictor.Stanford.EDU Joe Engelberger
C01712 00535 ∂26-Feb-88 2005 BRINK@Sushi.Stanford.EDU Letter of Recommendation (or the opposite)
C01714 00536 ∂27-Feb-88 0820 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu requested response
C01728 00537 ∂27-Feb-88 0821 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu requested response
C01742 00538 ∂27-Feb-88 0930 JMC
C01743 00539 ∂27-Feb-88 0958 hearn%hilbert@rand-unix.ARPA Re: requested response
C01748 00540 ∂27-Feb-88 1408 ARK SAIL out of CSD-CF
C01750 00541 ∂27-Feb-88 1730 hirani@jessica.Stanford.EDU Job
C01752 00542 ∂27-Feb-88 2321 RDZ@Score.Stanford.EDU The latest AIList
C01753 00543 ∂28-Feb-88 0004 RDZ@Score.Stanford.EDU re: The latest AIList
C01754 00544 ∂28-Feb-88 1612 RPG ISLISP
C01757 00545 ∂28-Feb-88 1632 TEICH@Sushi.Stanford.EDU my master's courses
C01758 00546 ∂28-Feb-88 1746 weening@Gang-of-Four.Stanford.EDU GNU Emacs function
C01761 00547 ∂28-Feb-88 2322 CWeissman.BSPO@DOCKMASTER.ARPA S/W Report
C01766 00548 ∂29-Feb-88 0328 ILAN@Score.Stanford.EDU re: Olympics
C01770 00549 ∂29-Feb-88 0900 RPG CPL
C01772 00550 ∂29-Feb-88 1128 yao.pa@Xerox.COM course description
C01774 00551 ∂29-Feb-88 1325 VAL book
C01775 00552 ∂29-Feb-88 1416 BSCOTT@Score.Stanford.EDU CPL Budget
C01777 00553 ∂29-Feb-88 1430 scherlis@vax.darpa.mil Re: CPL Budget
C01779 00554 ∂29-Feb-88 1437 littell@navajo.stanford.edu budget
C01783 00555 ∂29-Feb-88 1455 VAL copyright fees
C01784 00556 ∂29-Feb-88 1506 Qlisp-mailer QDOTIMES, QDOLIST
C01788 00557 ∂29-Feb-88 2315 SNOW@Sushi.Stanford.EDU AI course
C01790 00558 ∂29-Feb-88 2323 SNOW@Sushi.Stanford.EDU re: AI course
C01791 00559 ∂01-Mar-88 1100 JMC
C01792 00560 ∂01-Mar-88 1119 VAL McDermott on the frame problem
C01801 00561 ∂01-Mar-88 1344 ullman@navajo.stanford.edu PACO project
C01805 00562 ∂01-Mar-88 1431 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01807 00563 ∂01-Mar-88 1503 helen@psych.Stanford.EDU Dinner tonight?
C01808 00564 ∂01-Mar-88 1532 helen@psych.Stanford.EDU re: Dinner tonight?
C01809 00565 ∂01-Mar-88 1628 MPS National Geographic
C01810 00566 ∂01-Mar-88 1632 MPS More
C01811 00567 ∂01-Mar-88 2257 RFC Prancing Pony Bill
C01813 00568 ∂02-Mar-88 0801 JMC
C01814 00569 ∂02-Mar-88 0919 jbn@glacier.stanford.edu Re: two paths to AI
C01816 00570 ∂02-Mar-88 0949 GINSBERG@Sushi.Stanford.EDU no Formfeed this week
C01819 00571 ∂02-Mar-88 1107 SHOHAM@Score.Stanford.EDU $
C01820 00572 ∂02-Mar-88 1215 TEICH@Sushi.Stanford.EDU stopping by your office
C01821 00573 ∂02-Mar-88 1403 GINSBERG@Sushi.Stanford.EDU Formfeed mailing list installed!
C01822 00574 ∂02-Mar-88 1407 VAL Reply to McDermott's message
C01826 00575 ∂02-Mar-88 1413 VAL book
C01827 00576 ∂02-Mar-88 1507 ILAN@Score.Stanford.EDU Re: state of computer chess
C01831 00577 ∂02-Mar-88 1530 ilan@Gang-of-Four.Stanford.EDU HITECH's address
C01832 00578 ∂02-Mar-88 2000 JMC
C01833 00579 ∂03-Mar-88 0054 ilan@Gang-of-Four.Stanford.EDU
C01844 00580 ∂03-Mar-88 0816 Qlisp-mailer Regarding a possible inconsistency in Catch/Throw.
C01849 00581 ∂03-Mar-88 1041 Qlisp-mailer QDOTIMES, Matrix multiply
C01852 00582 ∂03-Mar-88 1248 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C01854 00583 ∂03-Mar-88 1340 STAGER@Score.Stanford.EDU Re: industrial lectureships
C01856 00584 ∂03-Mar-88 1349 yuly@csv.rpi.edu opinion
C01857 00585 ∂03-Mar-88 1407 STAGER@Score.Stanford.EDU CS350
C01858 00586 ∂03-Mar-88 1437 RDZ@Score.Stanford.EDU Quick question
C01859 00587 ∂03-Mar-88 1633 STAGER@Score.Stanford.EDU re: industrial lectureships
C01861 00588 ∂03-Mar-88 1653 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C01863 00589 ∂03-Mar-88 2152 Qlisp-mailer Regarding a possible inconsistency in Catch/Throw.
C01868 00590 ∂03-Mar-88 2248 @ELEPHANT-BUTTE.SCRC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Askey letter
C01872 00591 ∂03-Mar-88 2314 RDZ@Score.Stanford.EDU Meeting tomorrow
C01874 00592 ∂04-Mar-88 0057 cheriton@Pescadero.stanford.edu CSD Comp. The Second Coming
C01879 00593 ∂04-Mar-88 0202 RDZ@Score.Stanford.EDU Industrial lectureships
C01880 00594 ∂04-Mar-88 0340 TEICH@Sushi.Stanford.EDU re: stopping by your office
C01882 00595 ∂04-Mar-88 0700 JMC
C01883 00596 ∂04-Mar-88 0700 JMC
C01884 00597 ∂04-Mar-88 0812 Qlisp-mailer Juggling (Catch and Throw with Multiple Processes)
C01887 00598 ∂04-Mar-88 0854 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU New Draft
C01891 00599 ∂04-Mar-88 0857 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Full Text of Draft
C01963 00600 ∂04-Mar-88 0907 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU One other note
C01966 00601 ∂04-Mar-88 1126 ARK Re: industrial lecturers
C01967 00602 ∂04-Mar-88 1304 THOMASON@C.CS.CMU.EDU JPL article
C01968 00603 ∂04-Mar-88 1347 VAL CS326 - please reply as soon as possible
C01970 00604 ∂04-Mar-88 1502 Qlisp-mailer new-qlisp
C01972 00605 ∂04-Mar-88 1509 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: industrial lecturers
C01974 00606 ∂04-Mar-88 1518 WALDINGER@WARBUCKS.AI.SRI.COM Re: industrial lecturers
C01975 00607 ∂04-Mar-88 1638 ARK CS309 course description
C01979 00608 ∂04-Mar-88 1650 VAL Commonsense and Nonmonotonic Reasoning Seminar
C01981 00609 ∂04-Mar-88 1726 SINGH@Sierra.Stanford.EDU Faculty support sought for position on Immigration Laws
C01986 00610 ∂04-Mar-88 1732 WIEDERHOLD@SUMEX-AIM.Stanford.EDU CS309
C01987 00611 ∂05-Mar-88 0759 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU a comment--what do you think?
C01991 00612 ∂05-Mar-88 1435 weening@Gang-of-Four.Stanford.EDU
C01993 00613 ∂05-Mar-88 1448 JSW
C01994 00614 ∂06-Mar-88 1859 Qlisp-mailer no meeting this week
C01995 00615 ∂06-Mar-88 2301 ARK Revised CS309 course description
C01998 00616 ∂07-Mar-88 0855 TALEEN@Score.Stanford.EDU Re: Nagorno-Karabakh
C02003 00617 ∂07-Mar-88 1052 REIS@Sierra.Stanford.EDU High Noon Lecture
C02005 00618 ∂08-Mar-88 0553 @ELEPHANT-BUTTE.SCRC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Prof Moriarty an unindicted co-collaborator?
C02011 00619 ∂08-Mar-88 1204 tom@polya.stanford.edu SAIL's operating expense/budget
C02013 00620 ∂08-Mar-88 1327 wheaton@athena.stanford.edu SAIL's operating expense/budget
C02015 00621 ∂08-Mar-88 1333 wheaton@athena.stanford.edu SAIL's operating expense/budget
C02017 00622 ∂08-Mar-88 1346 SHOHAM@Score.Stanford.EDU no ride
C02018 00623 ∂08-Mar-88 1542 CLT mail
C02019 00624 ∂08-Mar-88 1605 BA.GLK%RLG.BITNET@forsythe.stanford.edu LISP, SAIL QUESTIONS
C02021 00625 ∂08-Mar-88 1609 nilsson@Tenaya.stanford.edu SAIL's operating expense/budget
C02023 00626 ∂08-Mar-88 1817 ARK re: SAIL's operating expense/budget
C02027 00627 ∂09-Mar-88 0711 ball@navajo.stanford.edu re: SAIL's operating expense/budget
C02030 00628 ∂09-Mar-88 0721 tom@polya.stanford.edu SAIL's operating expense/budget
C02032 00629 ∂09-Mar-88 1017 GINSBERG@Sushi.Stanford.EDU Formfeed tomorrow
C02033 00630 ∂09-Mar-88 1230 RDZ@Score.Stanford.EDU Hertz Luncheon March 25
C02034 00631 ∂09-Mar-88 1434 tom@polya.stanford.edu sail costs
C02035 00632 ∂09-Mar-88 1501 GINSBERG@Sushi.Stanford.EDU formfeed room change: March 10 ONLY
C02036 00633 ∂10-Mar-88 0906 MPS ttac meeting
C02037 00634 ∂10-Mar-88 0935 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU triangles
C02040 00635 ∂10-Mar-88 1024 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
C02042 00636 ∂10-Mar-88 1120 Qlisp-mailer Amount of idle time with cutoff d in Fibonacci
C02046 00637 ∂10-Mar-88 1125 Qlisp-mailer re: Amount of idle time with cutoff d in Fibonacci
C02048 00638 ∂10-Mar-88 1141 Qlisp-mailer Amount of idle time with cutoff d in Fibonacci
C02052 00639 ∂10-Mar-88 1306 Qlisp-mailer We Need An Accounting Equation
C02056 00640 ∂10-Mar-88 1418 yuly@csv.rpi.edu
C02058 00641 ∂10-Mar-88 1420 MPS Flights
C02059 00642 ∂10-Mar-88 1459 pehoushe@Gang-of-Four.Stanford.EDU Oh, you meant "What's the Point of the previous analysis?"
C02064 00643 ∂10-Mar-88 1504 Qlisp-mailer Re: Amount of idle time with cutoff d in Fibonacci
C02067 00644 ∂10-Mar-88 1619 perlis@yoohoo.cs.umd.edu a puzzle about introspection
C02074 00645 ∂10-Mar-88 1713 CLT msg
C02075 00646 ∂10-Mar-88 2000 JMC
C02076 00647 ∂10-Mar-88 2010 Qlisp-mailer Re: Scheduler inefficiencies
C02082 00648 ∂11-Mar-88 0853 ball@navajo.stanford.edu Re: SAIL charges
C02085 00649 ∂11-Mar-88 1040 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C02087 00650 ∂11-Mar-88 1434 scherlis@vax.darpa.mil quarterly reports
C02089 00651 ∂11-Mar-88 1445 FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: supercomputer center comments
C02091 00652 ∂11-Mar-88 1512 nilsson@Tenaya.stanford.edu supercomputer center comments
C02092 00653 ∂11-Mar-88 1633 VAL Commonsense and Nonmonotonic Reasoning Seminar
C02095 00654 ∂11-Mar-88 1645 SHOHAM@Score.Stanford.EDU lin
C02097 00655 ∂11-Mar-88 1754 helen@psych.Stanford.EDU Hi there, got your message
C02098 00656 ∂11-Mar-88 1857 helen@psych.Stanford.EDU re: Hi there, got your message
C02099 00657 ∂11-Mar-88 2128 binford@anaconda.Stanford.EDU supercomputer center comments
C02101 00658 ∂12-Mar-88 1134 HALPERN@IBM.COM Re: supercomputer center comments
C02102 00659 ∂12-Mar-88 1243 CSL.ALLISON@Sierra.Stanford.EDU Re: supercomputer center comments
C02103 00660 ∂12-Mar-88 1255 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: supercomputer center comments
C02105 00661 ∂12-Mar-88 1339 helen@white.stanford.edu Hi there, late as usual
C02106 00662 ∂12-Mar-88 1344 helen@Gang-of-Four.Stanford.EDU A second try
C02107 00663 ∂12-Mar-88 1345 helen@white.stanford.edu re: Hi there, late as usual
C02108 00664 ∂13-Mar-88 0140 DEK Yegorichev's book
C02109 00665 ∂13-Mar-88 1304 Q4034%PUCC.BITNET@forsythe.stanford.edu test of mail
C02111 00666 ∂13-Mar-88 1343 reif@cs.duke.edu Re: quarterly reports
C02113 00667 ∂13-Mar-88 1354 Q4034%PUCC.BITNET@forsythe.stanford.edu letter
C02116 00668 ∂13-Mar-88 1515 RDZ@Score.Stanford.EDU Shannon's paper
C02117 00669 ∂13-Mar-88 2339 SHOHAM@Score.Stanford.EDU re: lin
C02118 00670 ∂14-Mar-88 0900 JMC
C02119 00671 ∂14-Mar-88 1244 SHOHAM@Score.Stanford.EDU admissions committee chair
C02120 00672 ∂16-Mar-88 1156 MKATZ@A.ISI.EDU Visit to Stanford
C02122 00673 ∂16-Mar-88 1157 GINSBERG@Sushi.Stanford.EDU Reminder: NO FORMFEED TOMORROW
C02123 00674 ∂16-Mar-88 1229 weening@Gang-of-Four.Stanford.EDU
C02131 00675 ∂16-Mar-88 1313 SHOHAM@Score.Stanford.EDU so it is
C02132 00676 ∂16-Mar-88 1353 GINSBERG@Sushi.Stanford.EDU would either of you like to read a play this Sunday?
C02133 00677 ∂16-Mar-88 1358 Qlisp-mailer A proposed QDOTIMES syntax
C02136 00678 ∂16-Mar-88 2025 @Score.Stanford.EDU:adobe!plantin!rovner@decwrl.dec.com Follow-up on Yakov Eliashberg
C02140 00679 ∂17-Mar-88 0405 @DIAMOND.S4CC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Yegorichev's book
C02145 00680 ∂17-Mar-88 0409 ARK SAIL Report
C02149 00681 ∂17-Mar-88 0849 BSCOTT@Score.Stanford.EDU ARPA Formal Reasoning
C02152 00682 ∂17-Mar-88 1033 SHOHAM@Score.Stanford.EDU letter(s)
C02157 00683 ∂17-Mar-88 1125 MPS phone call
C02158 00684 ∂17-Mar-88 1125 MPS Hi-noon lecture
C02159 00685 ∂17-Mar-88 1131 MPS Ltr of Reference
C02160 00686 ∂17-Mar-88 1331 MPS presentationn
C02161 00687 ∂17-Mar-88 1711 GENESERETH@Score.Stanford.EDU Re: supercomputer center comments
C02162 00688 ∂17-Mar-88 1841 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
C02165 00689 ∂18-Mar-88 0551 solvberg%vax.runit.unit.uninett@TOR.nta.no IFIP Working Conf. in China, July 4-8 '88, Visa for invited speakers.
C02192 00690 ∂18-Mar-88 0904 CLT taxes
C02193 00691 ∂18-Mar-88 1019 CLT pills
C02194 00692 ∂18-Mar-88 1354 MPS grades
C02195 00693 ∂18-Mar-88 1405 LIBRARY@Score.Stanford.EDU tech report
C02197 00694 ∂18-Mar-88 1551 MPS telephone
C02198 00695 ∂18-Mar-88 1714 VAL Nonmonotonic seminar: no meeting
C02199 00696 ∂18-Mar-88 2327 FEIGENBAUM@SUMEX-AIM.Stanford.EDU Are we having fun yet?
C02206 00697 ∂19-Mar-88 0252 GLB
C02207 00698 ∂19-Mar-88 1047 CLT 13mar notes on algol again
C02211 00699 ∂19-Mar-88 1049 CLT oops
C02212 00700 ∂19-Mar-88 1240 CLT oops
C02213 00701 ∂20-Mar-88 1548 barwise@russell.stanford.edu common knowledge
C02215 00702 ∂20-Mar-88 1826 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU triangles
C02217 00703 ∂20-Mar-88 2118 CLT
C02218 00704 ∂21-Mar-88 0032 LIN draft
C02220 00705 ∂21-Mar-88 0044 CLT find yuen
C02221 00706 ∂21-Mar-88 0048 CLT find yuen
C02222 00707 ∂21-Mar-88 0918 MPS Trip to Washington
C02223 00708 ∂21-Mar-88 0948 CLT Okner
C02224 00709 ∂21-Mar-88 1103 MPS taxes
C02225 00710 ∂21-Mar-88 1132 jcm@ra.stanford.edu statement to Congress on supercomputers
C02230 00711 ∂21-Mar-88 1150 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: statement to Congress on supercomputers
C02231 00712 ∂21-Mar-88 1202 GENESERETH@Score.Stanford.EDU Re: Lin Fangzhen
C02233 00713 ∂21-Mar-88 1340 HALPERN@IBM.COM Re: statement to Congress on supercomputers
C02234 00714 ∂21-Mar-88 1344 GENESERETH@Score.Stanford.EDU re: Lin Fangzhen
C02235 00715 ∂21-Mar-88 1446 jlh@vsop.stanford.edu Re: statement to Congress on supercomputers
C02237 00716 ∂21-Mar-88 1501 jlh@vsop.stanford.edu Re: statement to Congress on supercomputers
C02238 00717 ∂21-Mar-88 1525 helen@Gang-of-Four.Stanford.EDU
C02244 00718 ∂21-Mar-88 1525 helen@Gang-of-Four.Stanford.EDU
C02247 00719 ∂21-Mar-88 1528 REIS@Sierra.Stanford.EDU Re: title and abstract
C02249 00720 ∂21-Mar-88 1537 REIS@Sierra.Stanford.EDU re: title and abstract
C02250 00721 ∂21-Mar-88 1823 FEIGENBAUM@SUMEX-AIM.Stanford.EDU statement
C02252 00722 ∂21-Mar-88 2242 FEIGENBAUM@SUMEX-AIM.Stanford.EDU party
C02255 00723 ∂22-Mar-88 0324 SOSTOYAN%DKNKURZ1.BITNET@forsythe.stanford.edu mail test
C02257 00724 ∂22-Mar-88 0629 AI.BRANTON@R20.UTEXAS.EDU Retirement Refund
C02258 00725 ∂22-Mar-88 1037 CLT house
C02259 00726 ∂22-Mar-88 1238 MPS Expenses
C02260 00727 ∂22-Mar-88 1550 BMOORE@Warbucks.AI.SRI.COM Re: a puzzle about introspection
C02263 00728 ∂22-Mar-88 1955 GLB
C02264 00729 ∂23-Mar-88 1000 JMC
C02265 00730 ∂23-Mar-88 1024 GINSBERG@Sushi.Stanford.EDU formfeed meets tomorrow
C02266 00731 ∂23-Mar-88 1117 SLOAN@Score.Stanford.EDU
C02268 00732 ∂23-Mar-88 2041 perlis@yoohoo.cs.umd.edu Re: a puzzle about introspection
C02273 00733 ∂24-Mar-88 1102 perlis@yoohoo.cs.umd.edu original problem
C02279 00734 ∂24-Mar-88 1123 ULLMAN@Score.Stanford.EDU Re: statement to Congress on supercomputers
C02280 00735 ∂24-Mar-88 1503 JSW Hertz luncheon
C02287 ENDMK
C⊗;
∂01-Jan-88 0950 AI.THROOP@R20.UTEXAS.EDU Stuck Tile and Bug Fix
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 1 Jan 88 09:50:29 PST
Date: Fri 1 Jan 88 11:50:45-CST
From: David Throop <AI.THROOP@R20.UTEXAS.EDU>
Subject: Stuck Tile and Bug Fix
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12363168107.9.AI.THROOP@R20.UTEXAS.EDU>
I've been looking at a position which I call Stuck8. It occurs when
the 8-tile is in space 10 and the blank is in space 9. It occurs fairly
frequently in the solutions that I'm generating.
It takes the system ~2100 nodes, and a search to 22 ply, to find a
move combination that advances play. Finding a way out of this position
often dominates the quality of the answer - roughly a third of the
variation in the systems success at solving random boards turns on
whether in stumbles into this hole. This combination completes the 2nd
row - there are no intermediate states that are BETTER between the
position
1 2 3 4
5 6 7 11
:BLANK 8 10 12
14 9 13 15
and
1 2 3 4
5 6 7 8
:BLANK 12 10 11
14 9 13 15
However, there is a 13 move sequence that completes the 2nd row:
1 2 3 4
5 6 7 11
:BLANK 8 10 12
14 9 13 15
0 moves
1 2 3 4
5 6 7 11
14 8 10 12
:BLANK 9 13 15
1 moves
1 2 3 4
5 6 7 11
14 8 10 12
9 :BLANK 13 15
2 moves
1 2 3 4
5 6 7 11
14 8 10 12
9 13 :BLANK 15
3 moves
1 2 3 4
5 6 7 11
14 8 :BLANK 12
9 13 10 15
4 moves
1 2 3 4
5 6 7 11
14 :BLANK 8 12
9 13 10 15
5 moves
1 2 3 4
5 :BLANK 7 11
14 6 8 12
9 13 10 15
6 moves
1 2 3 4
5 7 :BLANK 11
14 6 8 12
9 13 10 15
7 moves
1 2 3 4
5 7 8 11
14 6 :BLANK 12
9 13 10 15
8 moves
1 2 3 4
5 7 8 11
14 6 12 :BLANK
9 13 10 15
9 moves
1 2 3 4
5 7 8 :BLANK
14 6 12 11
9 13 10 15
10 moves
1 2 3 4
5 7 :BLANK 8
14 6 12 11
9 13 10 15
11 moves
1 2 3 4
5 :BLANK 7 8
14 6 12 11
9 13 10 15
12 moves
1 2 3 4
5 6 7 8
14 :BLANK 12 11
9 13 10 15
13 moves
The system fails to find this combination for several reasons. First,
it breaks the two-row restriction - after moves 1, 2 and 3, the blank is
in the last row. Secondly, after move 5 it breaks the chain, making
tiles 5 and 6 non-contiguous. Thirdly, if the two-row restriction were
suspended, after move 5 there is an additional 5-move combination that
moves tile 8 into square 12 and decreases the Manhattan distance.
In general, I'm not a fan of the two-row restriction - it is true, in
the sense that a solution always does exist which doesn't violate it,
and it does prune a certain number of fruitless moves. But it also
prunes a lot of good moves, and leads to longer answers. I think that
the good it does could be done by a weaker rule.
We have already discussed the inefficiency caused by using the whole row
as the chain, rather than just its last two elements.
For now, we could probably live with the inefficiency caused by the
Manhattan Distance getting greedy and leading to a suboptimal solution.
The important thing seems to be to allow the intermediate islands so
that this one problem doesn't so dominate the search.
=================================
BUG!
The code for Manhattan-Distance should read
(def-better-heuristic Manhattan-distance (newboard oldboard)
(let* ((nexttile (1+ (board-completed-chain oldboard)))
(currentpos (current-position nexttile oldboard)))
(unless (equal (position-contents currentpos newboard) ; If the tile hasn't changed position,
nexttile) ; don't calc the manhattan distance.
(and
(> (man-dist nexttile currentpos (board-side oldboard))
(man-dist nexttile (current-position nexttile newboard)
(board-side oldboard))) ; The final = test checks to prohibit undoing
(>= (completed-chain newboard) ; the existing complete chain.
(board-completed-chain oldboard)))) ; ERROR WAS IN THIS LINE.
))
This change only seems to make small differences in efficiency in most
positions.
David
-------
∂02-Jan-88 1243 BRINK@Sushi.Stanford.EDU 50 out of 45
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 12:43:21 PST
Date: Sat 2 Jan 88 12:42:17-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: 50 out of 45
To: hemenway@Sushi.Stanford.EDU
cc: jmc@Sail.Stanford.EDU
Message-ID: <12363461479.14.BRINK@Sushi.Stanford.EDU>
If I recall correctly, I have 50 units for my 45 unit MS. If we were to drop
the 399 course from the Proposal, would that clear me in time for fall quarter,
or would it take just as long as to get the grade on, say, Tuesday (i.e.,
winter quarter in either case)? It would probably take a day or two to get the
required signatures on the new Proposal, of course.
Again, I'm not panicking either wqy; just want to get it cleared up for fall if
possible.
Thanks.
..Ed
-------
∂02-Jan-88 1327 BRINK@Sushi.Stanford.EDU The Project
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:27:55 PST
Date: Sat 2 Jan 88 13:26:49-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: The Project
To: jmc@Sail.Stanford.EDU
Message-ID: <12363469587.14.BRINK@Sushi.Stanford.EDU>
Dr. McCarthy,
I have not been working as closely with you, or even Vladimir, on this as I had
expected to. The bulk of the work has been with MRS, and Vladimir is of course
not an expert on that. Mike Genesereth has been too hard to reach, so I have
gotten no information from him, though he did once express enthusiasm for the
idea. So this has been entirely on my own.
I have only a very hazy idea what level of detail is appropriate for a report
on a project such as this. Although the job is not nearly finished, I am
rather proud of the work I have done so far. It has been very much a detective
story, trying to learn the esoterica of Lisp while seeing what Mike has done
with it. I suspect, for example, that there may be some trauma associated with
converting MRS from ZetaLisp to Common Lisp, if he has used the disembodied
property list as much as I think he has. (I'm still learning.)
I have no running code, nor anything very close, but there are the beginnings
of functions scattered through the English algorithm which will give the idea
of how I intend to proceed.
I will be back at work full time beginning Monday, so I cannot expect to
continue at the same rate as in the past. I believe I can commit to most of
Saturday each week if that seems appropriate, but I have better things to do if
it isn't necessary. I really think this is turning into a job of dissertation
proportions or slightly less, and I'm not sure what the appropriate path is
from here on. If it is to be seriously pursued I would think Mike should be
formally brought into the picture. His advice would save days of sleuthing.
You probably can't grade the 399 by Monday noon as Sharon needs it, so I will,
I assume, need to register for TGR this quarter or something, so it can be done
for Winter quarter end. That is whether or not you think I'm fit for the PhD.
On the PhD itself, there seem to be three possibilities: yes, no and maybe. If
yes, I would just work on the project enough to keep from forgetting, and
intend to pursue it for real again in the fall. If no, I would probably not do
more on it unless there were some other arrangement in the offing. If maybe, I
should do whatever I can by whenever you need it, given I'm at work again. In
that case I think I would benefit by some sessions with you, discussing it.
This note is meant to be a discussion opener, not a final statement. I've
attached the report and the work itself, including one of Mike's functions with
my comments added. I have commented a few of his other functions to some
degree less than that of MATCH.LISP, but most of the things I have deduced are
in MRSFNS.DOC. I await your opinion and direction.
Thanks for the opportunity.
..Ed
-------
∂02-Jan-88 1330 BRINK@Sushi.Stanford.EDU The Report
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:30:20 PST
Date: Sat 2 Jan 88 13:29:13-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: The Report
To: jmc@Sail.Stanford.EDU
cc: val@Sail.Stanford.EDU
Message-ID: <12363470022.14.BRINK@Sushi.Stanford.EDU>
Towards an Implementation of the Inverse Method in MRS (A Progress Report)
Edwin W. Brink
Stanford University
January 2, 1988
The Inverse Method is a means of doing the work of the resolution process in
larger chunks, and therefore hopefully more rapidly. It was developed in
Russia in the Sixties, and has a modern description in a recent paper by
Vladimir Lifschitz [1]. The present effort is directed toward an
implementation of the method in Lisp under the MRS system of Michael Genesereth
[2], in order to exhibit in a practical way the efficiency and generality shown
theoretically by Lifschitz.
The MRS system is finely tuned to the resolution process. The MRS data base is
a set representing the conjunction of its members. Its members are lists
representing sentences, which are in turn grouped into sets called theories.
The most common MRS sentence is a clause (a disjunction of literals). MRS
indexes sentences on the property lists of their constituent symbols. The
sentence p is given a unique name d, which is placed on the list constituting a
certain property of its first symbol. The entire sentence p is placed as the
"pattern" property of the symbol d which is its name.
In order to meaningfully incorporate the Inverse Method into MRS it is first
necessary to do three things: (1) define the Method algorithmically as a
program specification; (2) create internal documentation for the MRS system,
which comprises well over 400 Lisp functions in 25 separate packages on the TI
Explorer; and finally (3) incorporate the superclause concept into the MRS
mechanism at a reasonably low level. Only then can the actual functions for
the Inverse Method itself be written.
At this stage the first and second steps have been sufficiently well started to
allow beginning the third. The algorithmic definition [3] of the Rule B
portion of the Inverse Method is in its fourth iteration and needs only minor
alterations to reach final form. Rule A is simpler and its definition
therefore appears in the Lisp comments which constitute the program
specification [4].
The MRS internal documentation [5] now lists about 370 functions in fourteen
packages. Some 110 functions are described in detail along with their
variables, properties and macros; the others are merely identified with their
packages and sometimes with their position in the call tree or their major
results. The major functions which implement unification and resolution are
fully described, and other functions will be added as necessary.
The next step will be to decide on the representation for a superclause. At
this time the obvious choice is a list, headed by an OR operator, of lists each
headed by an AND operator. This is the standard MRS representation of a
disjunction of conjunctions. It is necessary, however, to determine whether
MRS can properly unify the segments of a superclause (see [1] for definitions)
under such a definition. This in turn requires considerable detail work
relating the MRS functions involved to the concepts defined in [3]. This is
perhaps the hardest part of the entire project; once this is done the rest is
likely to be a matter of programming and debugging. Some progress has been
made; it now appears that this representation is feasible.
I recommend continuing the project since it serves at least two purposes: (1)
investigation of the utility of the Inverse Method, and (2) internal
documentation of MRS itself. Prof. Genesereth should be actively involved; his
knowledge of MRS could make the work proceed considerably faster. The next
checkpoint should be reasonably soon, and should measure whether or not Rule A
can in fact be implemented using the scheme above. The code should be fairly
well debugged to that point before further work (on Rule B) is done.
The work is attached except for the MRS functions themselves. Many of them
have been annotated directly as well as represented in the internals document.
References:
1. Lifschitz, Vladimir A., "What is the Inverse Method?", unpublished draft,
Stanford University, 12 June 1987.
2. Genesereth, Michael R., "The MRS Manual", Stanford University Logic Group
Report LOGIC-87-3, Stanford University, March 1987.
3. Brink, Edwin W., "An Algorithm for the Application of the Minimal Rule B for
Predicate Calculus", attached.
4. Brink, Edwin W., TRUEP.LISP, attached.
5. Brink, Edwin W., Internal Documentation of MRS, attached. ≠
-------
∂02-Jan-88 1331 BRINK@Sushi.Stanford.EDU TRUEP.LISP
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:31:24 PST
Date: Sat 2 Jan 88 13:30:19-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: TRUEP.LISP
To: jmc@Sail.Stanford.EDU
cc: val@Sail.Stanford.EDU
Message-ID: <12363470224.14.BRINK@Sushi.Stanford.EDU>
;;; This defines truep as the Inverse Method theorem prover. It uses MRS'
;;; unification facilities to implement the Inverse Method.
(<= (must &n &a)
(is (act (task) &n) &a))
(<- (act (truep &p &x) &n)
(return (quotify (inversemethod (unquote &p) (unquote &x)))))
; An Algorithm for Inverse Method Theorem Proving in MRS
;
; (after V. Lifschitz, "What Is the Inverse Method?", draft, 6/12/87, herein
; referred to as "the paper".)
;
;
; Definitions:
;
; * A literal is a term representing one Boolean value. It may be a proposition
; or an instance of a predicate. In MRS it is represented by a list of atoms:
; one atom for a proposition, more for a predicate. Propositions look like
; (a) or (x); predicates are like (p &x) and (T (q (&y a))). Lisp atoms
; beginning with ampersands are MRS variables. Functions look like predicates
; in MRS; the only way to tell them apart is by their position in a construct,
; or the values they assume (truth or falsity for a predicate, arbitrary values
; for a function). Predicates may be defined over the ranges of functions,
; so that expressions like (p (f &x &y) &z) make sense, where p is a predicate
; and f a function over two truth values, and f returns a value appropriate
; for the first argument of p.
;
; * A clause is a set of literals. It represents a disjunction of Boolean
; values. In MRS a clause is represented as a sentence, a list of lists with
; possibly operators at the heads. Negation is represented by the operator
; "not", as in (not (a) (b) (not(c))). An MRS clause is equivalent to an MRS
; disjunction, which is represented by a sentence like (or (x y z)).
;
; * A superliteral is a conjunction of literals. MRS represents a conjunction
; by a sentence of the form (and (x y z)). Since it is a conjunction, the
; paper calls the i-th S-superliteral Ci.
;
; * A superclause is a disjunction of superliterals. In MRS we represent a
; superclause by a sentence such as (or (and (p &x) (q &y)) (r &m &n)). In
; this example there are two superliterals: [1] (and (p &x) (q &y)), and
; [2] (r &m &n). The latter is also a literal.
;
; * The MRS data base is a set representing the conjunction of its members. Its
; members are lists representing sentences. They are given names, grouped
; into sets called theories, and indexed both ways by their first symbols.
; The MRS manual and internal documentation cover this construction in some
; detail.
;
; * S represents the universe of discourse (the input) in an Inverse Method
; proof. It is a conjunction of, at most, superclauses; its value is "true".
; We represent S in MRS by a theory called S and one superclause in the input.
; The sentences of S represent superclauses, so they must be MRS clauses,
; MRS superliterals or at most MRS superclauses.
;
; * An S-clause is a clause (not a superclause) DERIVED from S during the course
; of an Inverse Method proof. The methods of derivation are described below
; and in the paper as Rule A and Rule B. The goal is to derive the empty
; clause and thus establish the inconsistency of S.
;
; * A segment CiBAR.XIi of an S-clause E is CiBAR, the negation of an
; S-superliteral Ci, possibly operated on by a substitution XIi. The segment
; is a clause since it is the negation of a conjunction of literals.
;
; * The most general unifier (MGU) of two or more segments is a substitution
; which makes all their (composite) substitutions identical. Their
; superliterals Ci must already have been identical.
;
; * If the substitution ETA is the MGU of two or more segments in E then E.ETA
; is called a factor of E. For each segment CiBAR.XIi we drop any parts of
; ETA whose domain does not include Ci.
;
; * CHOOSE below means choose any; the algorithm may w.l.o.g. do all choices
; in order from the top except where otherwise restricted, as at step 10.
;
; * The POOL is the set of available true clauses at any time during the course
; of an Inverse Method proof. At the start of the Rule B algorithm, the pool
; comprises all clauses generated by rule A. The pool is represented in MRS
; by the theory POOL.
;
; * The RESERVE is the set of clauses being generated during one pass over the
; pool in the course of a proof. It is added to the pool at the end of the
; pass. The OLD RESERVE is the reserve set from the most recent previous
; pass, which is also contained in the pool. During the first pass it is the
; entire pool. In MRS the reserve and old reserve are represented by the
; theories RESERVE and OLDRESERVE.
(defun inversemethod (Isuperclause &optional (answerliteral t) (Stheory theory))
; S is the set of superclauses formed by the data base theory Stheory and
; the input superclause Isuperclause.
(let (S) (cons Isuperclause (lookups &x &x Stheory)))
; Algorithm for Rule A:
; Form all minimal tautological clauses from the superclauses in S and place
; them in the pool.
;
; The first step is to find (in the superclauses of S) disjuncts (superliterals)
; which, when negated to become clauses (segments), form tautologies either
; taken singly or disjoined in pairs. Substitutions may be required in order to
; induce the tautologies. Only those substitutions are permitted which meet the
; minimality conditions of the paper, p.16, q.v.
;
; We order the superliterals of S in the obvious way: by superliteral within
; clause. We then try each pair (1:2, 1:3, ..., 2:3, ..., n:n), STASHing in the
; pool each tautology successfully derived. The function SLC turns a superliteral
; into a clause by negating it and dropping the "and" and "or" connectives. As
; each such clause is formed we add it to a temporary list CLIST used in the actual
; trials, which use the functions TAUT1 and TAUT2. Each returns a tautology
; formed by unifying its two input clauses, or NIL if it cannot.
;
; A tautology formed by TAUT1 or TAUT2 has attached to it any substitutions
; performed in the process. This is necessary (instead of merely performing the
; substitutions) in order to perform Rule B below. In the case of the minimal
; tautology of the first kind (two literals from the same superliteral, one
; negated, are unified), TAUT1 calls the MRS function UNIFYP which returns an
; association list representing the unifying substitution.
;
; For a minimal tautology of the second kind (two literals from different segments
; C1 and C2), TAUT2 does a renaming substitution on one clause, say C2, to
; standardize the parameters apart, then finds the mgu of a literal in one
; clause and the negative of a literal in the other. C1 then carries the mgu as
; its substitution, and C2 carries the composition of the two substitutions.
; Negating and disjoining the two clauses produces the tautology.
(defun slc (sl) (clauses (cnfmaknot sl)))
(defun taut (x y)
(
(kill '(&x) 'POOL) ; everybody out of the pool
(
(let ttlgy)
(and (setq ttlgy (taut x1 x2))
(stash ttlgy 'POOL))
; Algorithm for Rule B:
; (N.B: This construct should look a lot like mrg's function grs in GENERAL.LISP.)
; (But (grs p c) uses (rules p) to get a list of all clauses with the same header
; to resolve with. There's as yet no similar thing for superclauses...)
; Set the OLD RESERVE equal to the pool.
;
; The RESERVE is a list of clauses starting as the empty list.
(let RESERVE '())
(do
; 1. Choose an S-superclause C containing superliterals C1, ... Cn.
;
((C superclause (cdr C))
(ans ()))
((null C) ans)
(let (Ci (car C)))
; 2. For each superliteral Ci of C, choose from the pool a clause or factor Ei
; containing CiBAR.XIi for some (possibly empty) XIi.
;
(choose Ei from POOL)
; 3. For each Ei, choose a renaming substitution ALPHAi, so as to standardize
; apart the parameters of the Ei's. (ALPHA1 can always be the empty
; substitution {}.)
;
(choose ALPHAi to standardize Ei apart from
the others (gensym?))
(nconc ans XIi.ALPHAi) ; ans is a list of all XIi.ALPHAi
)
; 4. Find ETA, the MGU of the composite substitutions XIi.ALPHAi.
;
(do (()
)
(Find ETA, the MGU of the XIi.ALPHAi in ans)
)
; 5. Give each ALPHAi.ETA the name ETAi. (Then all the composite substitutions
; XIi.ETAi are equal; the paper calls their value ZETA.)
;
; 6. Generate a clause, the OR of all the E'i.ETAi, where E'i is Ei with
; CiBAR.XIi deleted. If it is not already in the pool or the reserve, add it
; to the reserve.
;
; 7. Repeat from step 2, choosing a new Ei for the last i for which any choices
; remain which generate a previously unseen combination of Ei's. For each i
; after the one replaced, start over with the first possible Ei. (The effect
; is one of counting in some bizarre base, the units digit being at the
; right, i.e., i=n.)
;
; 8. When all Ei combinations have been exhausted for this C, repeat from step 1.
;
; 9. When the last C is finished, add the reserve to the pool, replace the old
; reserve by the reserve and clear the reserve.
;
; 10. Begin a new level from the first C at step 1. Restrict the choice at
; step 2 so that at least one Ei from the old reserve is included every
; time, thus insuring no reruns of previous generation steps.
;
; 11. Whenever the empty clause is generated, quit and announce success.
;
; 12. If no new clauses are generated at step 6 for some level, quit and
; announce failure.
;
≠
-------
∂02-Jan-88 1333 BRINK@Sushi.Stanford.EDU MRSFNS.DOC
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:33:00 PST
Date: Sat 2 Jan 88 13:31:54-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: MRSFNS.DOC
To: jmc@Sail.Stanford.EDU
cc: val@Sail.Stanford.EDU
Message-ID: <12363470511.14.BRINK@Sushi.Stanford.EDU>
Internal Documentation of MRS
This is a list, with descriptions, of most of the functions of MRS. It includes
all functions in BASE, CNF, DEMODULATION, FUNCTIONS, GENERAL, INFERENCE,
INTERFACE, MATCH, ORDER, PERFORM, PROPREP, SIMPLE, SIMPLIFY and TRANSLATE. The
remaining packages are for the most part interface or application oriented and
not concerned with the basic function of MRS. At present many functions are not
yet described; work is still in progress.
The "calls" and "called by" notations below are not meant to be complete, just
indicative.
The MRS manual pages quoted herein are from at least two different paginations
of the manual, and so are only approximate.
The MRS data base is a set representing the conjunction of its members. Its
members are lists representing sentences. These lists are grouped into sets
called theories. The MRS manual covers this construction in more detail.
MRS indexes clauses on the property lists of their constituent symbols. The
sentence p is given a unique name d, which is placed on the list constituting
the 'fdata, 'bdata, 'ndata, 'pdata or 'gdata property of its first symbol
according as the clause is a disjunction with a negated first subclause, one
with a positive first subclause, a negated clause, a positive clause or an MRS
metalevel relation (head is "<-" or "<+" ). The symbol d is in the hash table
"names"; its key is p. The entire sentence p is placed as the 'pattern property
of d! See the functions index, unindex and pattern, and the properties.
The following diagram illustrates this, with "↑" indicating the position of the
symbol on whose property list the clause is indexed.
'gdata (<- (↑ ...
(<+ (↑ ...
'ndata (not ((↑ ...
'fdata (or ((not ((↑ ... [relindex]
(or ((not ((↑ ... )) )) ... ((not ((↑ ... [index]
'bdata (or ((↑ ... [relindex]
(or ((↑ ... )) ... ((↑ ... [index]
[The function "index" puts the clause name on the 'fdata or 'bdata property of
the head of every subclause in a disjunction; "relindex" does only the first
subclause.]
'pdata (↑ ...
The names are apparently meant to be suggestive of general, negative, forward,
backward and positive data respectively.
Values are assigned to variables by association lists. The variable &x has the
value v in environment (theory) t if there is a member of the form (&x (v t)) on
the appropriate association list.
The "Where" column indicates which of the packages of MRS contains the source
code for the object named in the "What" column.
What Where
Explanation (either from MRS manual, implementation notes, or reading the
code)
MACROS
defobject (x &rest l) interface
deftheory (x &rest l) interface
PROPERTIES
* simplify
simp-* simplify
+ simplify
simp-+ simplify
- simplify
simp-- simplify
// simplify
simp-// simplify
↑ simplify
simp-↑ simplify
alike base
virtualpalike virtualp
bdata proprep
Name of rules property of a symbol used in positive disjuncts and thus in
backward chaining. (getp 'x 'bdata) produces a list of the names of the data
base clauses (disjunctions) containing terms (disjuncts) which are (positive)
sentences with x as head (car). Only the head is used because it is treated
as a predicate; the rest are the things of which it is true.
call demodulation
getvalcall lisp
call demodulation
getvalef getval
call demodulation
ngetvalcall lisp
call demodulation
ngetvalef ngetval
call simplify
simplifycall lispfunction
cond demodulation
getvalcond specialgetval
cond demodulation
ngetvalcond specialngetval
fdata proprep
Like bdata, but the disjuncts are negative, e.g., (NOT(X)). The result is
useful in forward chaining. gdata proprep Name of defuns property of a symbol.
The 'gdata property of p is a list of the names of all clauses which are MRS
metalevel relations ( <-, <+ ) having p for the head of their first subclause.
global proprep
focus active
if demodulation
getvalif specialgetval
if demodulation
ngetvalif specialngetval
is base
virtualpis virtualp
lambda demodulation
getvallambda specialgetval
lambda simplify
getvallambda specialsimplify
lambda demodulation
ngetvallambda specialngetval
ln simplify
simp-ln simplify
log simplify
simp-log simplify
map demodulation
getvalmap getval
map demodulation
lookupef lookup
map demodulation
lookupef lookup
map demodulation
ngetvalmap ngetval
map simplify
simplifymap simplify
mq simplify
getvallambda specialsimplify
ndata proprep
Like fdata, but used by (units p) instead of (rules p), and is a list of
negative singleton instances in the data base, e.g., (NOT(P x)) by itself.
pdata proprep
Like ndata, but a list of positive instances, e.g., (P X).
rat simplify
simp-rat simplify
unalike base
virtualpunalike virtualp
unknown base
virtualpunknown virtualp
unprovable base
virtualpunprovable virtualp
VARIABLES
actives nil proprep
The list of active theories. See MRS manual p. 12.
alist nil demodulation, order
An association list; a special variable in DEMODULATION, defvar as nil in
ORDER..
dfs order
A flag: t if doing dfs instead of just df
existentials cnf
List of existentially quantified variables (cf the fn "clauses" & the var
"universals")
falsity match
'((nil . nil))
focus global proprep
manual nil interface
names make-hash-table proprep
occurcheck nil match
Non-null means "do the occurrence check in the unification process".
result order
results order
save inferen
A switch: non-null := save all intermediate conclusions to the data base as
they are derived. See MRS manual p. 49 and all assume and truep fns.
task perform
theories nil proprep
A list of all theories containing at least one sentence. See MRS manual p.
53.
theory 'global proprep
The name of the current default theory. See MRS manual p. 54.
thing order
traceclauses nil inferen
List of clauses to be traced during inference. See MRS manual p. 55.
traceliterals nil inferen
List of literals to be traced during inference. See MRS manual p. 56.
truth match
'((t . t))
universals cnf
List of universally quantified variables (cf the fns "skolem", "clauses" & the
var "existentials").
FUNCTIONS
abl (l) functions
activate (th) proprep
Makes th active: its sentences are available for retrieval and its name goes
on the list "actives". See MRS manual p. 10.
activep (th) proprep
Nil unless th is active. See MRS maual p. 11.
addbagof (v) cnf
addexist (v) cnf
addl (x l) functions
addm (x l) functions
addp (x y z) functions
addq (x l) functions
adduniv (v) cnf
alconc (al1 al2) match
Nil if al1 empty, al2 if its cdr empty, else...
allookup (p al) order
amongp (x y) base
assume (p &opt (th theory)) inference
Call perform on the metalevel task (assume (mq s)). The metalevel assume is
defined by the user. See MRS manual p. 14.
assq (x al) Steele
p. 281: "assoc" using the "eq" test instead of "eql"
backup (bl) match
Null out all the values in assoc list bl, leaving the variables there.
bagof (x p) inference
bc (pl thing) inference
Backward chain ...
bccall (p al cl el) inference
bccut (cl el) inference
bclisp (p al cl el) inference
bcpop (cl el) inference
bcpush (pl al cl el) inference
bcrs (p al cl el) inference
bcs (pl thing) inference
bcun (p al cl el) inference
bcvirt (p al cl el) inference
beforep (c d) interface
bfdass (fringe) sc
Guts of bfdassume.
bfdassume (p &opt (th theory)) sc
Resolve & store breadth first, deterministic, p vs. data base. Call bfdass.
See MRS manual p. 14.
bfgass (fringe) general
Guts of bfgassume.
bfgassume (p &opt (th theory)) general
Resolve & store breadth first, general, p vs. data base. Call bfgass. See
MRS manual p. 15.
bfgtrp (fringe) general
Guts of bfgtruep.
bfgtrps (fringe) general
bfgtruep (p &opt (x t) (th theory)) general
Resolve & return breadth first, general, p vs data base. Return answer in x.
Call bfgtrp. See MRS manual p. 16 and CS225A implementation note 1.
bfgtrueps (p &opt (x t) (th theory)) general
bfoass (fringe) order
Guts of bfoassume.
bfoassume (p &opt (th theory)) order
Resolve & store breadth first, ordered, p vs. data base. Call bfoass. See
MRS manual p. 17.
bfotrp (fringe) order
Central loop of bfo inference proc. Fringe is a queue of clauses. Empty
fringe => nil; answer- literal fringe => its arg. Otherwise take 1st elt off
fringe, add its conclusions to end. See CS225A implementation note 1.
bfotrps (fringe) order
bfotruep (p &opt (x t) (th theory)) order
Breadth first resolution, one case, report only what unifies w/x, use theory
th. See MRS manual p. 18.
bfotrueps (p &opt (x t) (th theory)) order
Breadth first resolution, all cases, report only what unifies w/x, use theory
th.
clauses (p) cnf
Convert the sentence p to a list of clauses. E.g., ( and (p) ( or (q) (r) ) )
become ( ((p)) ((q) (r)) ). See CS225A implementation note 1.
cnf (p) cnf
Convert sentence p to conjunctive normal form. See MRS manual p. 19.
cnfmaknot (p) cnf
Stick a 'not in front of p or remove one if it's there. See CS225A
implementation note 1.
cnfmaksand (l) cnf
Stick an 'and in front of l if it's not a singleton
cnfmaksor (l) cnf
Turn clause l into the corresponding MRS sentence by sticking an 'or in front
if it's not a singleton. See CS225A implementation note 1.
cnfs (p) cnf
cnfsands (l) cnf
cnfsors (l) cnf
cnfsvars (p) cnf
cntp (x th) proprep
Refocus on th. Return t if there's an active theory on the 'theories list of
x, else nil. A theory is "active" if its 'active property is non-null. In
the fn "focus" the 'active proerty can take on the value nil, 'activate,
'focus or 'both.
cntxt (dat th) proprep
The global var theories (q.v.) is a list of all theories with at least one
sentence. Iff th is not on that list, it is also not a member of the
'theories property of dat. In that case put it in both places and put dat on
its 'contents property.
conp (x y z) functions
Add y to front of list which is x's z property.
contents (th) proprep
(getp th 'contents)
data (r) proprep
List of all data base rules containing r as head of any clause.
deactivate (th) proprep
Remove theory th from active status and its name from the list 'actives. See
MRS manual p. 20.
defineobject (obj facts) interface
definetheory (theory facts) interface
defocus (th) proprep
Change the 'active property of th from 'both to 'activate or from 'focus to
nil. When refocus calls defocus it also changes the value of the global
'focus from th to some other theory's name.
defuns (p) proprep
Get 'gdata prop of caadr p. See gdata above.
delact (&opt (th theory)) perform
MRS' deliberation-action loop. On each cycle, use dfotruep to find a value
for &a in the query (must n &a) and do it. See MRS manual p. 22 and CS225A
implementation note 2.
dell (x l) functions
Take x out of list l and return the result. If it's not there return l.
Called by delp.
delp (x y z) functions
Take y off the list which is x's z property. If the list is now empty, remove
the property and return nil. Called by uncntxt.
demo (f) interface
den (x) simplify
df (pl thing) order
dfcall (p al cl el) order
dfcut (cl el) order
dflisp (p al cl el) order
dfoassume (p &opt (th theory)) order
Depth first assume
dfdas (p) sc
Return nil if p is known (see knownp), else call dfdasrs on the negation of p
if p is in the data base.
dfdasrs (p) sc
Guts of dfdassume. Called by dfdas, use more dfd routines.
dfdass (pl) sc
Call dfdas on the car of pl.
dfdassume (p &opt (th theory)) sc
Resolve and store depth first, deterministic, p vs. data base. Call dfdass.
See MRS manual p. 21.
dfgass (fringe) general
Guts of dfgassume. Call gconcs, others.
dfgassume (p &opt (th theory)) general
Resolve and store depth first, general, p vs. data base. Call dfgass. See
MRS manual p. 22.
dfgtrp (fringe) general
Guts of dfgtruep. Call gconcs, others.
dfgtrps (fringe) general
dfgtruep (p &opt x t) (th theory)) general
Resolve and return depth first, general, p vs data base. Call dfgtrp. See
MRS manual p. 23.
dfgtrueps (p &opt (x t) (th theory)) general
dfoassume (p &opt (x t) (th theory)) order
Resolve and store depth first, ordered, p vs. data base. See MRS manual p.
24.
dfotruep (p &opt (x t) (th theory)) order
Depth first resolve, one case, report only what unifies w/ x, use theory th.
MRS manual p. 25. The MRS version of PROLOG, complete with cuts.
dfotrueps (p &opt (x t) (th theory)) order
Depth first resolve, all cases, report only what unifies w/ x, use theory th
dfpop (cl el) order
dfpush (pl al cl el) order
dfrs (p al cl el) order
dfs (pl thing) order
Do all possible df's and reverse order of "results".
dfstrp (pl thing) sc
Called by dfstruep; call dfstrppush.
dfstrpcall (p pl al) sc
Called by dfstrppush. Set up dfstrpun when needed.
dfstrppop (al) sc
Called by dfstrppush.
dfstrppush (pl al) sc
Called by dfstrp, dfstrps; call dfstrppop, dfstrpcall.
dfstrpun (p pl al) sc
The unifier for dfstruep. Call cntp, unify, dfstrppush, backup.
dfstruep (p &opt (x t) (th theory)) sc
Resolve and return depth first, sequential, p vs. data base. Satisfy
constraints. Call dfstrp. See MRS manual p. 26.
dfun (p al cl el) order
dfvirt (p al cl el) order
dgetval (x &opt (th theory)) demodulation
The MRS interpreter used in deriving the values of expressions in proving "is"
sentences. Return the value obtained by bottom up interpretation
(demodulation) on x using the sentences in th, its includees and all active
theories. Call gv. See MRS manual p. 27.
distribute (c d) cnf
dnfs (p) cnf
dnfsands (l) cnf
dnfsors (l) cnf
doall (&rest l) perform
dsimp (x) simplify
dsimpcall (f x) simplify
dsimpenv (x alist) simplify
dsimplify (x &opt (th theory)) simplify
Like dgetval but try to avoid certain errors by just simplifying the
expression. MRS manual p. 30.
dsimpun (x) simplify
dssq (x l) functions
dump (f) interface
Dump the MRS data base into file f which can be loaded again using "load".
See MRS manual p. 28.
empty (&opt (th theory)) proprep
factp (p &opt (x t) (th theory)) base
If there is a substitution instance of p in th or its includees or any active
theory, apply the substitution to x, else return nil. Call indexps, matchp,
pattern, plug. MRS manual p. 29.
factps (p &opt(x t) (th theory)) base
Like factp but return a list using all substitution instances of p. See MRS
manual p. 30.
facts (x th) base
fc (pl) inference
Forward chain ...
fccall (p al cl el) inference
fccut (cl el) inference
fclisp (p al cl el) inference
fclookup (p al) inference
fcpop (cl el) inference
fcpush (pl al cl el) inference
fcrs (p al cl el) inference
fcsave (p al cl el) inference
fcsavep (cl) inference
fcun (p al cl el) inference
fcvirt (p al cl el) inference
fd (pl) order
fdcall (p al cl el) order
fdcut (cl el) order
fder (p al cl el) order
fdlisp (p al cl el) order
fdpop (cl el) order
fdpush (pl al cl el) order
fdrs (p al cl el) order
fdsave (p al cl el) order
fdsavep (cl) order
fdun (p al cl el) order
fdvirt (p al cl el) order
findfile (c) ?
Return the file spec of the file wherein c is defined as a constant, else nil.
MRS manual p. 31.
focus (th) proprep
Set the 'active property of th (a symbol, the name of a theory) to 'focus or
'both (implies 'focus and 'activate). When refocus calls focus it also sets
the global variable 'focus to th.
forget (p &opt (th theory)) inference
Call perform on the metalevel task (forget (mq p)). User writes the metalevel
forget using, e.g., undb. See MRS manual p. 25.
freevars (x) cnf
freevarsexp (x bl fl) cnf
funp (f) transla
gconc (p pl) general
gconcs (c) general
geqp (x y) (not (greaterp y x)) functions
getn (x z) functions
getp (x z) functions
If x a symbol, get (x z)
getval (x &opt (th theory)) inference
Call perform on the metalevel task (getval (mq x)). User writes the metalevel
getval using, e.g., dgetval. See MRS manual p. 36.
getvalcall (f x) demodulation
getvalcond (x) demodulation
getvalef (x) demodulation
getvalif (x) demodulation
getvallambda (x) demodulation
getvalmap (x) demodulation
glisp (p c) general
Do lisp fn p to clause c for side effect only, and delete not-p from c,
returning the rest.
groundp (x) cnf
grs (p c) general
General ReSolve.
gun (p c) general
General UNify.
gv (x) demodulation
The guts of dgetval. Call gvvar, gvconst, getvalef, gvun. See the
DEMODULATION package for details.
gvcall (f x) demodulation
gvconst (x) demodulation
gvenv (x alist) demodulation
gvirt (p c) general
Do virtual fn p to clause c and return the result at end of c, with all
variables substituted and not-p, if any, removed.
gvun (x) demodulation
gvvar (x) demodulation
includees (c) proprep
Return a list of theories directly included in c. See MRS manual p. 34.
includers (c) proprep
Return a list of theories directly including c. See MRS manual p. 35.
includes (t1 t2) proprep
Set up the data base so that t1 includes t2. Make trans[de]activate on t1
affect t2. See MRS manual p. 36.
indb (p &opt (th theory)) base
Add sentence s to theory th unless s is virtual or already there. See MRS
manual p. 37.
indbp (p &opt (th theory)) base
Return the name of any sentence (in th or any active theory) which is same as
p up to variable renaming. If p is virtual, call the proper procedure on it.
See MRS manual p. 38.
index (p) proprep
Give p a name. If p a <- or <+ sentence, put the name on the 'gdata property
list of p's first predicate. If a "not" sentence, put it on its 'ndata list.
If an 'or sentence, on the 'fdata lists of all 'not subpredicates and the
'bdata lists of the others. Otherwise put it on the 'pdata list of its car
(first predicate). Return nil if p an atom; else return its name UNLESS it's
an 'or clause (bug?). Call conp to do the putprop.
indexp (p) proprep
Return all names given to the subclauses of p by calling indexps on each.
indexps (p) proprep
Return the index property (name) of clause p as given to it by (index p).
instp (x y al) match
Return al, an association list representing a substitution, such that the
value it gives to x is (MQ y.) If it can't be done, then return nil.
kill (x &opt (th theory)) base
Remove from theory th every sentence containing a substitution instance of x.
See MRS manual p. 42.
knownp (p &opt(x t)(th theory)) simple
knownps (p &opt (x t) (th theory)) simple
leqp (x y) functions
loadassume (f &opt (th theory)) interface
Load the sentences in file f into theory th using assume. See MRS manual p.
40.
loadindb (f &opt (th theory)) interface
Load the sentences in file f into theory th using indb. See MRS manual p. 41.
loadmanual () interface
loadstash (f &opt (th theory)) interface
Load the sentences in file f into theory th using stash. See MRS manual p.
42.
lookup (p &opt(x t)(th theory)) simple
Convert sentence p to cnf. If a sentence in the data base unifies with p,
apply the unifying substitution to x and return the result. If p is virtual,
return the result of the corresponding procedure. Else return nil. See MRS
manual p. 43.
lookuplisp (p x) simple
lookups (p &opt(x t)(th theory)) simple
Like lookup but return a list. MRS manual p. 44.
lookupslisp (p x) simple
lookupsun (p x th) simple
lookupsvirt (p x) simple
lookupun (p x th) simple
lookupvirt (p x) simple
makclause (p cl) order
maksym (c) functions
Return a new symbol: c concatenated with the next integer not yet used with c.
manual (x) interface
matchp (p x) match
Like samep but less strict; use equal, not eql.
matchpexp (p x al) match
Like samepexp but use matchpvar and doesn't check that x is a var.
matchpvar (p x al) match
Like samepvar but use equal and return t instead of al when p, x already
match.
meml (x l) functions
Is x a member of list l? ( :test #'eql); equivalent to Common Lisp member(x
l) (the default test).
memq (x l) Steele
p.275: MacLisp: Is x a member of list l?; equivalent to Common Lisp member(x l
:test #'eq).
memmatchp (x l) base
metalevel axioms act, fringe .......
See CS225A implementation note 3.
mgup (p q) match
Find mgu of p, q. Call mgupexp.
mgupchk (p q al) match
Do the occurrence check (is q, e.g., F(p)?) for mgu.
mgupexp (x y al) match
Find mgu of expressions p, q.
mguvar (p q al) match
Find mgu of p, q, knowing p a variable.
mrgassume (p &opt (th theory)) inference
mrgforget (p &opt (th theory)) inference
mrgtruep (p &opt (x t) (th theory)) inference
mrgtrueps (p &opt (x t) (th theory)) inference
mtchp (x al y bl ol) match
mtchpboundp (x al) match
mtchpchkp (x y bl) match
mtchpempty () match
((t t)), an assoc list of one entry
mtchpenv (x al) match
The environment (cddr) of the first value pair for x in the assoc list al
mtchpinstp (x al y bl ol) match
mtchpinstpvar (x al y bl ol) match
mtchpset (x al y bl nl) match
If x has a value in assoc list al, then return ((x.(y.bl)).nl). Else return
((x (y.bl)).nl)) after inserting (x (y.bl)) in al just after the car.
mtchpsetnew (x y bl nl) match
Return ((x (y.bl)).nl) after inserting (x (y.bl)) in al just after the car.
mtchpsetold (x al y bl nl) match
Return (x.nl) after setting x to (car x).(y.bl).
mtchpunset (x al) match
Find the value of x in al and remove it. Return the truncated assoc list from
there on.
mtchpval (x al) match
The value (cadr) of the first value pair for x in the assoc list al
mtchpvar (x al y bl nl) match
mul (x y) simplify
name (p) proprep
Return a unique atom as name for sentence p. Return the same name for p as
long as p is stored in some theory. See MRS manual p. 45.
namep (p) proprep
Return the previously assigned unique name of p.
nconc &rest lists Steele
p.269: concatenate lists into one list, changing rather than copying as append
does.
newvar () proprep
Return a new variable &n, using the next n.
ngetval (x &opt (th theory)) demodulation
ngetvalcall (f x) demodulation
ngetvalcond (x) demodulation
ngetvalef (x) demodulation
ngetvalif (x) demodulation
ngetvallambda (x) demodulation
ngetvalmap (x) demodulation
num (x) simplify
nump (x) simplify
nv (x) demodulation
nvcall (f x) demodulation
nvconst (x) demodulation
nvenv (x alist) demodulation
nvun (x) demodulation
nvvar (x) demodulation
oconc (p pl) order
The guts of oconcs. Call olisp, ovirt, oun and ors to do the dirty work.
oconcs (pl) order
Return the list of all conclusions that can be drawn using ordered resolution
on the clause pl and the clauses in the current theories. See CS225A
implementation notes 1 and 3.
olisp (p pl) order
Perform a Lisp operation and return the result.
order (l) interface
ors (p pl) order
The basic Ordered ReSolve function.
oun (p pl) order
The basic Ordered UNify function.
ovirt (p pl) order
Perform the operation to derive a virtual value; return it.
pattern (n) proprep
The pattern property of n if n a symbol, else nil. The pattern property is
the data base sentence whose name is n. The name of p is given by (indexps p).
perform (task &opt (th theory)) perform
Bind the globals task and theory to the given task and th and call delact.
Used in defining assume, forget, getval, truep, trueps. See MRS manual p. 50
and CS225A implementation note 3.
plistp (x) functions
pls (x n nl rl) simplify
plsin (c x n nl rl) simplify
plsout (nl rl) simplify
plug (x al) match
Give x its value from the assoc list al: x if al has no pairs, else (plug1 x
al)
plug1 (x al) match
If x a var, x if no value or value eq x; else plug1 the value; else x if
atomic, else it's a list: plug1 its car & cdr.
plugal (al1 al) match
Fill in the value of the cdr of each pair in al1 by plugging from al using
that same cdr, not the car.
plugenv (x al) match
Find variables in clause x that have values in assoc list al. Return x with
the substitutions performed. If no value, return the variable's name. Used
for answer literals, e.g. in dfotruep, via oun.
plugstd (x al) match
Like plugenv except for a variable with no value, make and return a new
variable &n as its name. Called by ors.
prdata (l th) interface
pset (x y z) macros
((x . y) . z)
punset (x al) match
putn (x y z) functions
Used in putp: put the name y in the hash table.
putp (x y z) functions
If x a symbol, make its z property y (=putprop). Else do the same thing via
the hash table "plist".
quotify (x) inference
Return the list ('mq x). See MRS manual p. 48.
raise (x y) simplify
rat (x y) simplify
ratadd (x y) simplify
ratdiv (x y) simplify
ratmul (x y) simplify
ratp (x) simplify
ratpow (x n) simplify
ratsub (x y) simplify
red (n m) simplify
refocus (th) proprep
Change the value of the global variable 'focus from what it is to th. Call
focus on th and defocus on the old theory.
relindex (p) proprep
Like index, but in the 'or case, handle only the first subclause.
relunindex (d) proprep
Like unindex, but in the 'or case, handle only the first subclause.
remmanual () interface
remn (x z) functions
remp (x z) functions
repend (l m) functions
rules (p) proprep
Get 'fdata prop of caadr p if car p = 'not, else get 'bdata prop of car p. See
fdata and bdata above. These properties are the names of other rules like p
with the same caadr or car (i.e., the same first predicate).
samep (x y) match
If x and y can be made to match, return the assoc list that does it, else nil.
samepexp (x y al) match
Find or bind values for x, y in al. If they can be matched, return the
augmented al, else nil.
samepvar (x y al) match
If x a var with value in al, return al if y matches, nil if not. Else give x
the value y, return augmented al.
setm (&rest l) perform
show (x &opt (th theory)) interface
simp-* (p) simplify
simp-+ (p) simplify
simp-- (p) simplify
simp-// (p) simplify
simp-↑ (p) simplify
simp-ln (p) simplify
simp-log (p) simplify
simp-rat (p) simplify
simplify (x &opt (th theory)) inference
simplify-arith (p) simplify
simplifycall (f x) simplify
simplifymap (x) simplify
show (x &opt (th theory)) interface
Print out all substitution instances of x in theory th. Each sentence in an
active theory is marked by a + sign. Included theories are not used unless
explicitly named. See MRS manual p. 53.
skolem () cnf
snoc (l x) functions
stash (p &opt (th theory)) simple
Convert p to cnf, then add those disjunctions to th, returning the name of the
last one. See MRS manual p. 51.
sum (x y) simplify
theories (d) proprep
Return a list of all theories containing the sentence whose name is d. (These
are the "theories" property of the symbol d.) See MRS manual p. 52.
tms (x n bl el) simplify
tmsin (b e n bl el) simplify
tmsout (bl el) simplify
tracecall (p al cl el) inference
traceclause (p al cl) order
traceconc (c) inference
tracedone (p al cl el) inference
traceexit (p al cl el) inference
tracemessage (p cl el pr) inference
tracespaces (cl el) inference
tracetask (k) inference
tracetasks nil) inference
trans... various
See details below and MRS manual p. 57.
transactivate (th) proprep
Do "activate" on th, all included theories.
transcontents (th) proprep
transcontents1 (th nl) proprep
transdeactivate (th) proprep
Do "deactivate" on th, all includees.
transdefocus (th) proprep
transempty (th) proprep
transfactp ? ?
Do "factp" on th and all included theories.
transfacts (x th) base
transfacts1 (x th nl) base
transfocus (th) proprep
transforget ? ?
Do "forget x" on th, all includees.
transfun (f) translate
transgv (x) translate
transgvclause (parms args defn) translate
transgvtail (l) translate
transgvvarp (x) translate
transincludees (th) proprep
Do "includees" on th and its includees!
transincludees1 (th nl) proprep
transincluders (th) proprep
Do "includers" on th and its includees.
transincluders1 (th nl) proprep
transkill (x &opt (th theory)) base
Remove sentence x from th and all its includees.
transmatchp (x y) translate
transmrgforget (p &opt (th theory)) inference
transshow (x &opt (th theory)) interface
Do "show x" on th and its includees.
transundb (p &opt (th theory)) base
Do "undb p" on th and its includees.
transunstash (p &opt (th theory)) simple
Do "unstash p" in th and its includees.
transvarp (x y) translate
truep (p &opt (x t)(th theory)) inference
Call perform on the metalevel task, (truep (mq p) (mq x)) in the theory th.
Return a binding list for the first way it can prove p, else nil. See MRS
manual p. 61 and CS225A implementation note 3.
trueps (p &opt (x t)(th theory)) inference
Like truep but return a list of all possible binding lists. See MRS manual p.
59.
uncntxt (dat th) proprep
Take dat off the 'contents property of th. If thx now has no contents, take
it off the global list "theories". Take th off the 'theories property of dat.
In other words, the sentence named dat is no longer in the context of the
theory th.
undb (p &opt (th theory)) base
If th has a sentence equivalent to p (same up to var renaming), remove it and
return its name. If not or if p is virtual, return nil. See MRS manual p.
60.
unify (x al y bl) match
Call mtchp to unify x and y, ...
unifyp (x y) match
unincludes (t1 t2) proprep
Undo the effect of "includes". MRS manual p. 61.
unindex (d) proprep
Remove the name d from the property lists of the symbols of p, the sentence of
which d is the name. See index, pattern.
unionl (l m) functions
unionm (l m) functions
units (p) proprep
Get 'ndata prop of caadr p if car p = 'not, else get 'pdata prop of car p. See
ndata and pdata above. Gets a list of clauses in the data base whose head
matches that of p.
unname (d) proprep
unquote (x) inference
Take initial 'mq (metaquote) off x if one is there. See MRS manual p. 62.
unstash (p &opt (th theory)) simple
Convert p to cnf, then remove each conjunct from th, returning the name of the
last one removed. See MRS manual p. 63.
varp (x) proprep
Is x a variable?
vars (x) cnf
varsexp (x l) cnf
virtualpalike (p al) base
virtualpis (p al) base
virtualpunalike (p al) base
virtualpunknown (p al) base
virtualpunprovable (p al) base
≠
-------
∂02-Jan-88 1335 BRINK@Sushi.Stanford.EDU MATCH.LISP
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:33:52 PST
Date: Sat 2 Jan 88 13:32:44-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: MATCH.LISP
To: jmc@Sail.Stanford.EDU
cc: val@Sail.Stanford.EDU
Message-ID: <12363470663.14.BRINK@Sushi.Stanford.EDU>
;;; -*- Mode:Lisp; Package:USER; Syntax:ZETALISP; Base:10; Fonts:(CPTFONT) -*-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Please do not modify this file. See MRG. ;;;
;;; (c) Copyright 1980 Michael R. Genesereth ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(eval-when (compile)
(special truth occurcheck alist blist))
(defvar truth '((t . t)))
(defvar falsity '((nil . nil)))
(defvar occurcheck nil) ; Don't do the occurrence check in mguvar
(defun samep (x y) (samepexp x y truth)) ; If x and y can be matched, return the association list that does it, else nil.
(defun samepexp (x y al) ; Find or bind values for x and y in al.
(cond ((atom x) ; If they can be made to match, return the augmented al, else nil.
(cond ((varp x) (and (varp y) (samepvar x y al)))
((eql x y) al)))
((atom y) nil)
((setq al (samepexp (car x) (car y) al))
(samepexp (cdr x) (cdr y) al))))
(defun samepvar (x y al) ; If x has a value in al, return al if y matches the value, nil if not.
(let (dum) ; If it doesn't, give it y as a value and return al with that pair added.
(cond ((setq dum (assq x al)) (if (eq (cdr dum) y) al))
(t (pset x y al)))))
(defun matchp (p x) (matchpexp p x truth)) ; Like samep but less strict; uses equal instead of eql.
(defun matchpexp (p x al) ; Like samepexp but uses matchpvar and doesn't check that x is a var.
(cond ((atom p)
(cond ((varp p) (matchpvar p x al))
((eql p x) al)))
((atom x) nil)
((setq al (matchpexp (car p) (car x) al))
(matchpexp (cdr p) (cdr x) al))))
(defun matchpvar (p x al) ; Like samepvar but uses equal and returns t instead of al
(let (dum) ; when p, x already match.
(cond ((setq dum (assq p al)) (equal x (cdr dum)))
(t (pset p x al)))))
(defun mgup (p q) (mgupexp p q truth)) ; Find mgu of p and q
(defun mgupexp (x y al) ; Find mgu of two expressions x and y;
; return al with any more substitutions added.
; This is like the procedure in Genesereth & Nilsson p. 62.
; al is an assoc list of existing substitutions; the unifier is added to it.
(cond ((eq x y) al) ; The mgu IS al if x = y identically.
((atom x) (cond ((varp x) (mguvar x y al)) ; Try substituting current values for x. then y.
((varp y) (mguvar y x al))
((equal x y) al))) ; If no luck, allow equal.
((atom y) (cond ((varp y) (mguvar y x al)))) ; If y a var, try substituting for it.
((eq 'mq (car x)) (instp y (cadr x) al)) ; If x quoted, see if its head is a substitution instance of y.
((eq 'mq (car y)) (instp x (cadr y) al)) ; If y quoted, see if its head is a substitution instance of x.
((setq al (mgupexp (car x) (car y) al)) (mgupexp (cdr x) (cdr y) al)))) ; Do the list bit.
(defun mguvar (p q al) ; Find mgu of p, q knowing p a variable
(local (dum)
(cond ((setq dum (assq p al)) ; Find value of p, if any, in al
(mgupexp (cdr dum) q al)) ; Found; go unify it with q
((or (not occurcheck) ; Not found; do we do the occurrence check?
(not (mgupchk p q al))) ; Yes; can't unify P(x) and P(F(x))
(pset p q al))))) ; OK; set the new value of p to q in al
(defun instp (x y al) ; If y a SUBSTITUTION INSTANCE (only) of x,
(cond ((atom x) ; returns (x (MQ y)) on front of al. Returns al
; if y is already the value of x, NIL if x has another value.
; Does lists item by item.
(cond ((and (null x) (null y)) al) ; OK as is if both are null.
((not (varp x)) nil) ; No luck if x isn't a var.
((assq x al) ; Here x has a value on al, so if its third item is y return al.
(if (equal (caddr (assq x al)) y) al)) ; The second is MQ, I guess.
; If it isn't y, return NIL.
(t ; Here x is a variable with no value on al, so
(pset x (list 'mq y) al)))) ; give x the value 'y, on the assoc list al
((eq 'mq (car x)) ; So x is a list. If x is quoted then
(if (equal (cadr x) y) al)) ; if y is = the next item in x we are done.
((or ; If that didn't work, atomic or quoted y is no good.
(atom y)
(eq 'mq (car y)))
nil)
((setq al (instp (car x) (car y) al)) ; They're both lists, so go after the cars,
(instp (cdr x) (cdr y) al)))) ; then the cdrs of x and y recursively.
(defun mgupchk (p q al) ; The occurrence check: is p contained literally in q?
(cond ((eq p q)) ; OK if they're equal (nil means OK)
((varp q) ; If q a variable, check p against its value in al
(mgupchk p (cdr (assq q al)) al))
((atom q) nil) ; OK if q a constant
((or
(mgupchk p (car q) al) ; Else check p against each term in the clause q
(mgupchk p (cdr q) al)))))
(defun punset (x al)
(if (eq x (caar al)) (cdr al)
(do l al (cdr l) (null (cdr al))
(cond ((eq x (caadr l)) (rplacd l (cddr l)) (return al))))))
(defun plug (x al) (if (null (cdr al)) x (plug1 x al)))
(defun plug1 (x al)
(cond ((varp x)
(local (dum)
(cond ((null (setq dum (assq x al))) x)
((eq x (cdr dum)) x)
(t (plug1 (cdr dum) al)))))
((atom x) x)
(t (cons (plug1 (car x) al) (plug1 (cdr x) al)))))
(defun plugal (al1 al)
(mapcar '(lambda (l) (cons (car l) (plug (cdr l) al))) al1))
(defun alconc (al1 al2)
(cond ((null al1) nil)
((null (cdr al1)) al2)
(t (do ((l al1 (cdr l)))
((null (cddr l)) (rplacd l al2)))
al1)))
(defun unifyp (x y) (mtchp x (mtchpempty) y (mtchpempty) falsity)) ; Will x and y unify?
(defun unify (x al y bl) (mtchp x al y bl falsity)) ; Unifies x, y with their associated values.
(defun mtchp (x al y bl ol) ; Your basic unifier; cf mgup. Clauses x, y to be unified.
; Assoc lists al, bl = input values of vars in x, y. Assoc list
; ol = the list to which to add the values that make x, y match.
(cond ((atom x) ; Say x is an atom. Then
(cond ((varp x) (mtchpvar x al y bl ol)) ; if x a var, can we set it to y?
((eql x y) ol) ; if x=y, buy the list as is;
((varp y) (mtchpvar y bl x al ol)) ; if y a var, can we set it to x?
(t (backup ol)))) ; Failed. Return ol stripped (with no values).
((atom y) ; OK, say y is an atom and try the same thing.
(cond ((varp y) (mtchpvar y bl x al ol)) ; Since x isn't, this is a lot shorter.
(t (backup ol))))
((eq 'mq (car x)) (mtchpinstp y bl (cadr x) al ol)) ; Well, ok, x is quoted; is its second
; item a substitution instance of y?
((eq 'mq (car y)) (mtchpinstp x al (cadr y) bl ol)) ;... and vice versa.
((setq ol (mtchp (car x) al (car y) bl ol)) ; No dice. Try 'em recursively piece by
(mtchp (cdr x) al (cdr y) bl ol)))) ; piece, quitting at the first failure.
(defun mtchpvar (x al y bl nl)
(let (dum)
(cond ((setq dum (assq x al)) ; dum = value of x, if any
(cond ((null (cdr dum)) (mtchpsetold dum y bl nl))
(t (mtchp (cadr dum) (cddr dum) y bl nl))))
((or (not occurcheck) (not (mtchpchkp x y bl)))
(mtchpsetnew x al y bl nl)))))
(defun mtchpinstp (x al y bl ol)
(cond ((atom x)
(cond ((and (null x) (null y)) ol)
((varp x) (mtchpinstpvar x al y bl ol))))
((eq 'mq (car x)) (if (equal (cadr x) y) ol))
((atom y) (backup ol))
((eq 'mq (car y)) (backup ol))
((setq ol (mtchpinstp (car x) al (car y) bl ol))
(mtchpinstp (cdr x) al (cdr y) bl ol))))
(defun mtchpinstpvar (x al y bl ol)
(let (dum)
(cond ((setq dum (assq x al))
(cond ((null (cdr dum)) (mtchpsetold dum (list 'mq y) bl ol))
((equal (plugenv (cadr dum) (cddr dum)) y))
(t (backup ol))))
((or (not occurcheck) (not (mtchpchkp x y bl)))
(mtchpsetnew x al (list 'mq y) bl ol)))))
(defun mtchpchkp (x y bl)
(cond ((eql x y))
((atom y)
(let (dum)
(and (varp y)
(setq dum (assq y bl))
(mtchpchkp x (cadr dum) (cddr dum)))))
((or (mtchpchkp x (car y) bl) (mtchpchkp x (cdr y) bl)))))
(defun mtchpset (x al y bl nl) ; If x has a value in assoc list al, then return
(let (dum) ; ((x.(y.bl)).nl). Else return ((x (y.bl)).nl) after
(cond ((setq dum (assq x al)) (mtchpsetold dum y bl nl)) ; inserting (x (y.bl)) in al just after the car.
(t (mtchpsetnew x al y bl nl)))))
(defun mtchpsetold (x y bl nl) ; Return (x.nl) after setting x to
(rplacd x (cons y bl)) ; (car x).(y.bl).
(cons x nl))
(defun mtchpsetnew (x al y bl nl) ; Return ((x (y.bl)).nl) after inserting
(setq x (list* x y bl)) ; (x (y.bl)) in al just after the car.
(rplacd al (cons x (cdr al)))
(cons x nl))
(defun mtchpunset (x al) ; Find the value of x in al and remove it.
(do ((l al (cdr l))) ; Return the truncated assoc list from there on.
((null (cdr l)))
(cond ((eq x (caadr l)) (return (rplacd l (cddr l)))))))
(defun backup (bl) ; Nulls out all the values in the association list bl leaving the
; variables there.
(do ((l bl (cdr l)))
((null (cdr l)) nil)
(rplacd (car l) nil)))
(defun mtchpboundp (x al) (assq x al))
(defun mtchpval (x al) (cadr (assq x al)))
(defun mtchpenv (x al) (cddr (assq x al)))
(defun mtchpempty () (list '(t t)))
(defun plugenv (x al) ; Find variables in clause x that have values in assoc list al. Return x with the
(cond ((atom x) ; substitutions performed. If no value, return the variable's name.
(let (dum) ; Used for answer literals, e.g. in dfotruep.
(cond ((not (varp x)) x)
((setq dum (cdr (assq x al))) (plugenv (car dum) (cdr dum)))
(t x))))
((eq 'mq (car x)) x)
(t (cons (plugenv (car x) al) (plugenv (cdr x) al)))))
(defun plugstd (x al) ; Like plugenv except for a var with no value, make
(cond ((atom x) ; and return a new variable &n as its value.
(let (dum)
(cond ((not (varp x)) x)
((not (setq dum (cdr (assq x al))))
(setq dum (newvar))
(mtchpset x al dum nil nil)
dum)
((null (cdr dum)) (car dum))
(t (plugstd (car dum) (cdr dum))))))
((eq 'mq (car x)) x)
(t (cons (plugstd (car x) al) (plugstd (cdr x) al)))))
≠
-------
∂02-Jan-88 1352 BRINK@Sushi.Stanford.EDU Delenda
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 13:52:37 PST
Date: Sat 2 Jan 88 13:51:32-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: Delenda
To: jmc@Sail.Stanford.EDU
cc: val@Sail.Stanford.EDU
Message-ID: <12363474084.14.BRINK@Sushi.Stanford.EDU>
On rereading what I just sent you I notice two things that need correction:
1. There may be some doubt just what is my work and what is Genesereth's.
Everything is mine EXCEPT the Lisp in MATCH.LISP (and the rest of MRS) and
a very few (say 8) descriptions of top level functions in MRSFNS.DOC.
Those should all refer to the MRS manual. Some of my descriptions also
have references to the manual, but they are generally lower level. The
manual is extremely short and general.
2. There is a missing reference.
The algorithm for Rule B is in TRUEP.LISP, and I decided not to repeat it by
sending the original document. Vladimir has a fairly recent copy which is,
I believe, essentially the same as the current one.
..Ed
-------
∂03-Jan-88 1207 binford@anaconda supercomputing considered harmful
Received: from ANACONDA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 12:07:29 PST
Received: by anaconda (3.2/SMI-3.2)
id AA14398; Sun, 3 Jan 88 12:12:16 PST
Date: Sun, 3 Jan 88 12:12:16 PST
From: binford@anaconda (Tom Binford)
Message-Id: <8801032012.AA14398@anaconda>
To: JMC@sail.Stanford.EDU
Cc: faculty@score.Stanford.EDU
Subject: supercomputing considered harmful
John
I share your questioning.
Tom
∂04-Jan-88 0024 cheriton@pescadero.stanford.edu.stanford.edu Re: supercomputing considered harmful
Received: from PESCADERO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 00:24:20 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA07142; Mon, 4 Jan 88 00:23:59 PST
Date: Mon, 4 Jan 88 00:23:59 PST
From: cheriton@pescadero.stanford.edu.stanford.edu (David Cheriton)
Message-Id: <8801040823.AA07142@Pescadero>
To: JMC@SAIL.Stanford.EDU, faculty@SCORE.Stanford.EDU
Subject: Re: supercomputing considered harmful
Supercomputing is a political invention of the physicists to subvert money
from computer science to physics. Notice the "Office of Scientific Computing"
which basically just buys Crays, etc. for physicists is under the
computer and information sciences directorate. Similarly, all the money that
NSF has for networking research appears to go for phone bills for physicists
to get remote terminal or remote job entry (yes!!) to their supercomputers.
They have also invented "computational sciences" which include the computing
components of physics, chemistry, material science, etc. and of course
computer science - trying to make computer science defined as a set of
computer users, etc. I attended one SIAM meeting where one supposedly
acclaimed physicist pontificated that computer scientists should be working
on assemblers, languages, operating systems, etc. for supercomputers.
I was tempted to retort that at least we had super users (a la Unix) but
the joke would have been lost on this lost audience.
I definitely think there is a need for respected computer scientists to say
that this supercomputer nonsense contributes very little (if anything) to
computer science research. Label it as infrastructure for physics, etc.
and let it be judged under the appropriate priorities.
Unfortunately, I think the problem is political, not technical. Everyone
(except possibly the politicians) know that supercomputing has nothing to do
with computer science so we should not expect the vested interests to listen
to reasoned technical arguments. We need to lobby!
I think it is criminal that NSF provides such limited and questionably
structured and allocated funding for computer science given the importance
of computing in the current and future of the country. If it wasnt for
military funding, the US lead in CS would be lost, if it ever would have
existed, and the Japanese doing a repeat of the VCR story with computers.
Unfortunately, I feel we still have lots to worrry about there, and the enemy
for us is more within the country that outside.
∂04-Jan-88 0830 JMC
dr., plumber re hot water
∂04-Jan-88 0828 TAP public
I can`t get to the above file because of protection failure
∂04-Jan-88 0900 JMC
Chuck Williams
∂04-Jan-88 0952 CLT tap
To: ME
CC: JMC
could you please set up secretary privileges for
our new secretary TAP so she will have access
to protected files of JMC and CLT
I have not had anyone with secy privs before.
Do I need to change my directories?
Also we need to restore all of RAs files so
the new secretary can go through them and
copy relevant stuff into her area, then
they can be deleted again.
Thanks
∂04-Jan-88 1000 JMC
Pat about phone answering machine
∂04-Jan-88 1038 TAP conference call
thelma from alex jacobson office called regarding conference call at 5:oo
today. his number is 213-407-7997
pat
∂04-Jan-88 1300 JMC
Nafeh
∂04-Jan-88 1304 croft@safe.stanford.edu russell account
Received: from SAFE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:02:51 PST
Received: by safe.stanford.edu with Sendmail; Mon, 4 Jan 88 13:02:20 pst
Date: 4 Jan 1988 1302-PST (Monday)
From: Bill Croft <croft@safe.stanford.edu>
To: jmc@sail
Cc:
Reply-To: croft@safe.stanford.edu
Subject: russell account
------- Forwarded Message
Return-Path: <brad@russell.stanford.edu>
Received: from russell.stanford.edu by safe.stanford.edu with Sendmail; Tue, 22 Dec 87 14:33:06 pst
Received: by russell.stanford.edu (3.2/4.7); Tue, 22 Dec 87 14:35:34 PST
Received: by russell.stanford.edu (3.2/4.7); Mon, 21 Dec 87 14:18:01 PST
Date: Mon, 21 Dec 87 14:18:01 PST
From: MAILER-DAEMON@russell.stanford.edu (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: brad@russell.stanford.edu
Resent-Date: Tue 22 Dec 87 14:35:31-PST
Resent-From: Brad Horak <BRAD@Russell.Stanford.EDU>
Resent-To: croft@russell.stanford.edu
----- Transcript of session follows -----
>>> RCPT To:<johnmc@csli>
<<< 550 No such local mailbox as "johnmc", recipient rejected
550 johnmc@csli... User unknown
----- Unsent message follows -----
Received: by russell.stanford.edu (3.2/4.7); Mon, 21 Dec 87 12:02:14 PST
Date: Mon, 21 Dec 87 12:02:14 PST
From: brad (Brad Horak)
To: johnmc@csli
Subject: UNIX account creation
Hello, you now have a new account on the Russell Sun 3/280S. Your
login name is johnmc and your password is 28page. You may change
the password at any time on russell by using the command "passwd".
If you fall into a certain class, we will also have created an
account for you on the Sun called "alan". If this is so, you will
receive a piece of followup mail. Staff members who have alan
accounts will receive their mail and have their files on that
machine.
Your 2060 account (on turing/csli) has been frozen (read-only).
All your files have been moved to the Sun and your work must
now be done there.
-------
------- End of Forwarded Message
∂04-Jan-88 1315 AI.BRANTON@R20.UTEXAS.EDU Keys
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:15:05 PST
Date: Mon 4 Jan 88 15:15:30-CST
From: AI.BRANTON@R20.UTEXAS.EDU
Subject: Keys
To: mccarthy@SAIL.STANFORD.EDU
cc: ai.branton@R20.UTEXAS.EDU
Message-ID: <12363991814.28.AI.BRANTON@R20.UTEXAS.EDU>
Hi Dr. McCarthy. We got your message about leaving the keys in the
top drawer of your desk but when we looked, they weren't there. Do
you think you might have taken them with you? If so, can you drop
them in the mail to me?
Thanks.
Suezette
-------
∂04-Jan-88 1322 AI.BRANTON@R20.UTEXAS.EDU re: Keys
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:22:38 PST
Date: Mon 4 Jan 88 15:22:54-CST
From: AI.BRANTON@R20.UTEXAS.EDU
Subject: re: Keys
To: JMC@SAIL.STANFORD.EDU
cc: manning@RATLIFF.CS.UTEXAS.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 4 Jan 88 13:18:00-CST
Message-ID: <12363993160.28.AI.BRANTON@R20.UTEXAS.EDU>
No, we looked all over so I guess someone may have taken them.
Oh well, Happy New Year anyway.
Suezette
-------
∂04-Jan-88 1451 100 (from: tap on TTY76, at TV-141) class
you are teaching course 101-1
Computers: Their Nature, Use, and Impact
Tues and Thurs at 4:15 to 5:30 in Room 041
∂04-Jan-88 1456 100 (from: tap on TTY101, at TV-141) VTSS meeting
The 18th is a University vacation. Martin Luther King
Day.
The VTSS meeting and lunch is on the 25th from 11:00 to
1:00 in Room 271 of the Law School
∂04-Jan-88 1522 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
FORMALIZING COMMONSENSE KNOWLEDGE
IN AUTOEPISTEMIC LOGIC
Michael Gelfond (UI00%UTEP.BITNET@WISCVM.WISC.EDU)
University of Texas at El Paso
Thursday, January 7, 4:15pm
MJH 252
In this talk we show how autoepistemic logic can be applied to
such seemingly different domains as deductive databases, taxonomic
hierarchies, and temporal reasoning. In particular, a new and very simple
formalization of the Yale shooting problem will be presented.
∂04-Jan-88 1547 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:47:19 PST
Date: Mon 4 Jan 88 15:45:08-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12364019055.46.HENZINGER@Sushi.Stanford.EDU>
**************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
**************************************
The LOP seminar will continue this quarter, as usual on Fridays
11:30-12:30 in MJH 301 [bring-your-own-lunch style].
January 8: Dr. Vladimir Lifschitz (Stanford Univ.),
"Mathematical Models of Nonmonotonic Reasoning"
[NOTE: This first meeting will be for once in MJH 352!]
January 15: Dr. Natarajan Shankar (Stanford Univ.),
"Checking Proofs using the Boyer-Moore Theorem Prover"
[MJH 301]
-------
∂04-Jan-88 1537 BRINK@Sushi.Stanford.EDU Off the hook
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:37:20 PST
Date: Mon 4 Jan 88 15:36:07-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: Off the hook
To: jmc@Sail.Stanford.EDU
Message-ID: <12364017411.41.BRINK@Sushi.Stanford.EDU>
In case Sharon hasn't told you, she is removing CS399 from my Program Proposal
so I can graduate as of last quarter without requiring an immediate grade from
you. I have enough units without it. I wouldn't have put it on had I known
she would need the grade so fast.
Thanks.
..Ed
-------
∂04-Jan-88 1549 TAP xerox number
The xerox numbers have already been coded in the machines.
Yours is on acct 2DMA705
The number is 41176e
∂04-Jan-88 1611 GOTELLI@Score.Stanford.EDU Outside User Computer Account
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 16:10:59 PST
Date: Mon 4 Jan 88 16:09:48-PST
From: Lynn Gotelli <GOTELLI@Score.Stanford.EDU>
Subject: Outside User Computer Account
To: JMC@Sail.Stanford.EDU
cc: Gotelli@Score.Stanford.EDU
Message-ID: <12364023545.14.GOTELLI@Score.Stanford.EDU>
John, Jussi Ketonen has requested a Score computer account
for Stuart Kreitman who works for him at M A D. Jussi asked me
to contact you and verify that he is working on a research project
in conjunction with you. Before this computer account can be
approved it must fall into one of the categories of the
criteria for an outside user computer account. This requests
matches closest to "others may be granted access to computers
if it is required in support of a contract with Stanford or for
research collaboration with a Stanford employee or visiting scholar."
Would this computer account be used in support of one of your
contracts or research collaboration? Thanks, Lynn
-------
∂04-Jan-88 1658 coraki!pratt@Sun.COM Gurevich
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 16:58:19 PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA15605; Mon, 4 Jan 88 16:58:48 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA25874; Mon, 4 Jan 88 17:00:08 PST
Received: by coraki.uucp (4.0/SMI-1.2)
id AA00286; Mon, 4 Jan 88 16:40:14 PST
Date: Mon, 4 Jan 88 16:40:14 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801050040.AA00286@coraki.uucp>
To: jmc@sail.stanford.edu
Subject: Gurevich
John, did you get my message of a month or so ago asking you about what
you thought of Gurevich as a visiting professor? This matter is now
coming to a head as Almaden is on the verge of making him an offer
(i.e. probably next week). If you didn't get my message let me know
and I'll fill you in on the details.
-v
∂04-Jan-88 1658 edsel!jlz@labrea.stanford.edu ISO trip to Paris
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 16:58:42 PST
Received: by labrea.stanford.edu; Mon, 4 Jan 88 16:58:45 PST
Received: from sunvalleymall.lucid.com by edsel id AA12497g; Mon, 4 Jan 88 15:59:32 PST
Received: by sunvalleymall id AA12065g; Mon, 4 Jan 88 16:01:52 PST
Date: Mon, 4 Jan 88 16:01:52 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801050001.AA12065@sunvalleymall.lucid.com>
To: labrea!mccarthy%sail.stanford.edu@labrea.stanford.edu
Cc: edsel!jlz@labrea.stanford.edu,
labrea!les%sail.stanford.edu@labrea.stanford.edu
Subject: ISO trip to Paris
John,
Dick asked that I contact you regarding the Paris ISO trip. Dick
would like the QLISP contract to pay both his and Will Clinger's
flight to and from Paris. DARPA has agreed, in principle, with
this arrangement. We need only to get your approval and I can
get the paper work rolling. I understand that we must use an
american carrier for DARPA to pay for this trip. We will make
sure all constraints are taken care of. My net address:
"edsel!jlz"@labrea
I hope to hear from you soon.
Thank you.
---jan---
∂04-Jan-88 1832 MATHIS@A.ISI.EDU iso mtg Paris Feb 24-25
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 18:22:25 PST
Date: 4 Jan 1988 21:20-EST
Sender: MATHIS@A.ISI.EDU
Subject: iso mtg Paris Feb 24-25
From: MATHIS@A.ISI.EDU
To: Bobrow.pa@XEROX.COM
To: willc%tekchips.tek.com@RELAY.CS.NET
To: Dussud%AUSOME%TI-CSL@RELAY.CS.NET
To: rpg@SAIL.STANFORD.EDU, gregor.pa@XEROX.COM
To: Baggins@IBM.COM, Masinter.pa@XEROX.COM
To: Mathis@A.ISI.EDU, KMP@SCRC-STONY-BROOK.ARPA
To: Scherlis@VAX.DARPA.MIL, gls@THINK.COM
To: jmc@SAIL.STANFORD.EDU, edsel!jlz@LABREA.STANFORD.EDU
Cc: mcvax!inria.inria.fr!queinnec@UUNET.UU.NET
Message-ID: <[A.ISI.EDU] 4-Jan-88 21:20:59.MATHIS>
This is the list of the US delegation to the first ISO working
group meeting on Lisp standardization to be held in Paris on
February 24-25, 1988.
ISO/IEC JTC1/SC22/WG 16 Delegation:
Dick Gabriel, chair
Guy Steele
Bob Mathis
Patrick Dussud
Thom Linden
Larry Masinter
Will Clinger
Bill Scherlis
Kent Pitman
John McCarthy
Jan Zubkoff
Danny Bobrow
Gregor Kiczales
I don't think all these people will be there, but most will.
I will be going over to arrive Sunday 21st and return Friday 26th.
I would be glad to coordinate hotels if anybody has any suggestions.
I do want to know who is going and where you will be staying.
keep in touch, Bob
∂05-Jan-88 0547 enea!LISBET.LiU.SE!M-REINFRANK@uunet.UU.NET NMR-Workshop/Publication
Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 88 05:46:58 PST
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA21445; Tue, 5 Jan 88 08:46:31 EST
Received: by enea.se (5.57++/1.14)
id AA23367; Tue, 5 Jan 88 14:35:24 +0100 (MET)
Received: from LISBET (lisbet.liu.se) by majestix.liu.se; Tue, 5 Jan 88 14:25:41 +0100
Date: Tue 5 Jan 88 14:22:56
From: Michael Reinfrank <mre@ida.liu.se>
Subject: NMR-Workshop/Publication
To: ginsberg@sushi.stanford.edu, jmc@sail.stanford.edu, hayes.pa@xerox.com,
dekleer.pa@xerox.com, E-SANDEWALL@lisbet.liu.se
Cc: m-reinfrank@lisbet.liu.se
Message-Id: <6PEC3AU.R.M-REINFRANK@LISBET>
Hello,
we won't publish any proceeding of the NMR-Workshop, but Erik and I intend
to edit a collection of papers soon after the workshop. The plan is, basically,
to select some good contributions to the workshop and ask the respective
authors to prepare a revised version for the book. It's also planned to
be published already in 1988, otherwise it doesn't seem to make much
sense.
My question now is whether you would be interested in contributing to
that book?
With my best regards,
Michael
-------
∂05-Jan-88 0717 AI.BRANTON@R20.UTEXAS.EDU Keys
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 07:17:36 PST
Date: Tue 5 Jan 88 09:17:55-CST
From: AI.BRANTON@R20.UTEXAS.EDU
Subject: Keys
To: mccarthy@SAIL.STANFORD.EDU
cc: ai.branton@R20.UTEXAS.EDU, manning@RATLIFF.CS.UTEXAS.EDU
Message-ID: <12364188862.24.AI.BRANTON@R20.UTEXAS.EDU>
We found the keys!! They were where you said and Paul had given
them to Bruce Porter. Sorry for the confusion.
Suezette
-------
∂05-Jan-88 0818 GOTELLI@Score.Stanford.EDU re: Outside User Computer Account
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 08:18:05 PST
Date: Tue 5 Jan 88 08:16:58-PST
From: Lynn Gotelli <GOTELLI@Score.Stanford.EDU>
Subject: re: Outside User Computer Account
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 4 Jan 88 16:21:00-PST
Message-ID: <12364199610.15.GOTELLI@Score.Stanford.EDU>
John, Thank you for your reply about the outside computer account.
I have asked Martin Frost to find out what has gone wrong with
TAP@Sail. I added her new records to the TAX/USERS database on
12/22/87 and Sail should have recognized this new user on 12/23/87.
Hopefully the problem will be corrected today. Thank you, Lynn
-------
∂05-Jan-88 0819 TAP VTSS course
January 25 at 11:00 in Room 271 of Law School
∂05-Jan-88 0955 SHOHAM@Score.Stanford.EDU ai courses mtg
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 09:55:25 PST
Date: Tue 5 Jan 88 09:54:01-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: ai courses mtg
To: nilsson@Score.Stanford.EDU, jmc@Sail.Stanford.EDU,
feigenbaum@SUMEX-AIM.Stanford.EDU, winograd@CSLI.Stanford.EDU,
zm@Sail.Stanford.EDU, shortliffe@SUMEX-AIM.Stanford.EDU,
buchanan@SUMEX-AIM.Stanford.EDU, genesereth@Score.Stanford.EDU,
latombe@Whitney.Stanford.EDU, binford@Whitney.Stanford.EDU,
tenenbaum@SPAR-20.SPAR.SLB.COM, clancey@SUMEX-AIM.Stanford.EDU,
shoham@Score.Stanford.EDU, weise@Mojave.Stanford.EDU,
reges@Score.Stanford.EDU, snow@Sushi.Stanford.EDU
Message-ID: <12364217279.34.SHOHAM@Score.Stanford.EDU>
Reminder: a meeting will take place at Nils' conference room
(MJH 220) on Thursday the 7th at 3pm to discuss the present
and future of AI courses.
Yoav
-------
∂05-Jan-88 1000 JMC
neck pillow, safety of boiling water
∂05-Jan-88 1001 GILBERTSON@Score.Stanford.EDU Heating in Rm 356
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 10:01:33 PST
Date: Tue 5 Jan 88 10:00:22-PST
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: Heating in Rm 356
To: McCarthy@Score.Stanford.EDU, TAP@Sail.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12364218436.33.GILBERTSON@Score.Stanford.EDU>
Professor McCarthy,
Operations maintenance called me this morning to say they had checked on
your heating problem yesterday, and adjusted your thermostat. They thought
you should know that the heat only goes on in the office when the lights are
turned on. The system is working well now, when lights are "on".
-Edith
-------
∂05-Jan-88 1005 TAP your car
call Gary at 494-7676
∂05-Jan-88 1007 JUSTESON@Sushi.Stanford.EDU quick meeting
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 10:07:39 PST
Date: Tue 5 Jan 88 10:06:27-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: quick meeting
To: jmc@Sail.Stanford.EDU
Message-ID: <12364219541.20.JUSTESON@Sushi.Stanford.EDU>
Hi, John. I need to get a note from you to increase my space allocation
on Portia, the new student machine taking over from Sushi/Rocky. As it
stands I have room to store my C program for learning to read and write
Elamite, but I don't have enough room to compile it.
Just for your information, I'm TAing 50% time this quarter and next for
Martin Kay, who's teaching Terry Winograd's computational linguistics
courses this quarter and next.
Regards,
John Justeson
-------
∂05-Jan-88 1029 CLT $
have you moved the money from ufcu to union bank?
∂05-Jan-88 1051 TAP alphonse juilland
he would like you to call him at 321-7819
∂05-Jan-88 1138 TAP vtss 160
meets at 1:15 today in bldg 60 room 62p - to the
right of the church as you face it
∂05-Jan-88 1143 TAP
i am really feeling bad so went home. see you
tomorrow or will call if i don`t feel better.
∂05-Jan-88 1253 JUSTESON@Sushi.Stanford.EDU re: quick meeting
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 12:52:55 PST
Date: Tue 5 Jan 88 12:51:16-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: re: quick meeting
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 5 Jan 88 12:26:00-PST
Message-ID: <12364249547.23.JUSTESON@Sushi.Stanford.EDU>
There is a "Faculty Sponsorship Form" (paper) that I have to pick up at Sweet
Hall; it needs a physical signature. I'll drop it by your office, or in your
mailbox if you're not in.
John
-------
∂05-Jan-88 1313 VAL reply to message
[In reply to message rcvd 05-Jan-88 12:22-PT.]
Unfortunately, the meeting conflicts with CS326.
∂05-Jan-88 1341 JSW Alliant
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
LES@SAIL.Stanford.EDU, RPG@SAIL.Stanford.EDU,
IGS@SAIL.Stanford.EDU
I got a call from Jim O'Dell at Alliant today. Jim is the person who
they hired to work on various Lisp systems. He told me several bits of
bad news: Alliant is no longer planning to sell a Lisp product (i.e.,
Lucid Lisp), and he has been laid off, along with about 50 other people.
It sounds like they're in some trouble.
∂05-Jan-88 1817 jcm@navajo.stanford.edu Industrial Lectureship
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 18:17:35 PST
Received: by navajo.stanford.edu; Tue, 5 Jan 88 18:13:25 PST
Date: Tue, 5 Jan 88 18:13:25 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: Industrial Lectureship
To: JMC@sail.stanford.edu
I think Luca Cardelli from DEC SRC would be a worthwhile
person for one of these lectureships. His area of expertise
is in design and implementation of functional programming
languages, and I suspect a course on pragmatic issues
would have a fairly wide interest.
I don't know yet whether he would be interested. What is involved
in nominating someone?
John
∂05-Jan-88 1817 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [Allen.Newell@C.CS.CMU.EDU: [Allen.Newell@C.CS.CMU.EDU: Re: Schwartz visit?]]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 18:17:39 PST
Date: Tue, 5 Jan 88 18:17:07 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: [Allen.Newell@C.CS.CMU.EDU: [Allen.Newell@C.CS.CMU.EDU: Re: Schwartz visit?]]
To: nilsson@score.Stanford.EDU, jmc@sail.Stanford.EDU
Message-ID: <12364308866.20.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
PLEASE KEEP NEWELL'S MESSAGE CONFIDENTIAL FOR OBVIOUS REASONS....ED
---------------
Return-Path: <NEWELL@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 2 Jan 88 12:49:23 PST
Received: ID <NEWELL@C.CS.CMU.EDU.#Internet>; Sat 2 Jan 88 15:44:41-EST
Date: Sat 2 Jan 88 15:44:39-EST
From: Allen.Newell@C.CS.CMU.EDU
Subject: [Allen.Newell@C.CS.CMU.EDU: Re: Schwartz visit?]
To: feigenbaum@SUMEX-AIM.STANFORD.EDU
Message-ID: <12363461910.11.NEWELL@C.CS.CMU.EDU>
Ed: Thanks for the messge from Bob S. We have not had much feedback about
the JS visit on 18 Dec (although maybe Duane has). People have a strong
tendency after such meetings to each simply go their own way and attend to
other things in life. So I haven't been looking for feedback.
Here is a message I sent to Dana Scott in answer to his query about the
meeting (he was not in attendence). It captures my assessment pretty well,
so it may help to increase the efficiency of our conversation. It is
an internal CMU msg, natrually. And if you propogate my attitudes about
JS meeting and AI, the relevant thing for you, you might damp out the other
aspects -- not that its terribly private in any event.
In looking it over I note two corrections: (1) Mark Fox gave the other
symbolic AI presentation, mostly a history of ISIS research. He should just
be included in the listing, since JS's reactions were fundamentally the
same, although he did responds positively in general to the sort of applied
AI flavor of Mark's work (Mark was presenting his stuff primarily as another
attempt to educate Jack about the central nature of AI). (2) Raj can a picture
of speech research that was field-wide, not CMU centered (I typoed "AI"
instead of "CMU" in the msg).
Cheers, AN
---------------
Date: Sun 20 Dec 87 23:29:05-EST
From: Allen.Newell@C.CS.CMU.EDU
Subject: Re: Schwartz visit?
To: Dana.Scott@C.CS.CMU.EDU
In-Reply-To: <12360051242.13.D-SCOTT@C.CS.CMU.EDU>
Message-ID: <12360138586.36.NEWELL@C.CS.CMU.EDU>
Dana: (1) I assumed you knew Jack, he being a member of the CS theoretical
community and involved with program semantics, eg, on Ada using SetL. But
it doesn't sound like you do.
(2) Jack appears to be extremely opinionated about AI. His opinion is @u[not]
that he doesn't like AI (eg, not the opinion I associated with our friends at
Cornell for many years). Here is my two-bit characterization:
AI is very important.
Some good things were done some time ago.
These showed, among other things that the AI was very hard. (These
difficulties center around the combinatorial explosion in its many guises.)
Profound insights are needed to make further progress -- which show how
to get around these combinatorial difficulties.
Learning is a key element in AI.
Something is missing in the present symbolic formulation. This is indicated
by the problems of perception (mostly) but also motor behavior, and their
recalcitrance to the formualtions of symbol AI.
No such fundamental insights are in sight or even on the horizon. In
particular, none of the work on learning or expert systems shows any
sign of such advances, but is merely pushing complex programs around in
ever more elaborate structures, but without any sign of advance.
3. Jack is modestly knowledgeable about AI, although mostly ten years out of
date, and partly because of his attitudes.
4. There is more to it than the above. Jack believes strongly in sharp
analytic formulations that go to heart of things wiht proofs that characterize
the results. He dislikes and distrusts and is "very uncomfortable with" (to
use his words) more Baconian approaches. And he does seize opportunities to
assert that he thinks many workers in AI are just using buzz words and
generally are pretty low grade technical people.
5. The day at CMU (0830:1830 solid) was a good day in that it got all of the
above on the table in explicit form, so there could be little mistake about the
opinions and a good deal of disucssion of them. Jack is often quite silent in
meetings, but there was lots of spirited, even hot, interchange in this one.
6. The day at CMU was a bad day in that it does not appear that we moved Jack
one iota. I thought we CMU types gave a good performance -- on a par with the
kind of performances you have been a party to. To my biassed eye it was really
impressive. But Jack brought forth attidutes out of the abvoe list to Jaime's
work on derivational analogy, to Tom's work on learning, to my work on Soar, to
Herb's work on scientific discovery. (I think I've got all the symbolic AI
presentations listed.) In each case he was vigorously disputed, with some
epsilon conversational gains, perhaps, but with no real change in his position.
7. On the other hand, he was very positive on all the other stuff -- Kanade on
vision, Rashid on a quick review of Mach, Camelot, Avalon, ..., Kung on
architecture. He was also very positve on speech (Raj gave a beautiful
technical presentation that covered the whole field, not just AI). He asked
Raj for a full day technical update on the field to be held in Washington.
(And he did allow to me as how Herb was really impressive -- this was the first
time he had ever heard him talk.)
8. It is unclear what he will actually do and what impact the day actually had
on his future actions. That AI will decrease is quite clear. How much it will
is much less clear. Figures of 30% are being bandied about (for the field,
nothing about CMU per se), Duane things he has statements from Jack taht are
more like 10%. I believe the day at CMU could actually have made him
substantially more cautious, but I have no direct evidence for it and wouldn't
base any policy decisions on it.
9. It is not clear what the implications are for CMU-CSD as a whole. I would
expect increased support for vision, architectures, software, algorithms,
robotics, manufacturing, and conceivably even speech (though I doubt that,
actually). I think we came over as a first-class place consisting of
first-class scientists (one has to separate the judgment on AI from this
somewhat of course). So the department as a whole (including robotics) may do
ok, just with substantially diminished support for AI (of undetermined
magnitude -- our contract runs for the next 2+ years, so if we lose money to
him it will be because he actually goes back on the contracted amounts -- which
he has some capabilities to do).
10. As for the united front, Nico gave stirring support for AI generally in
its importance and about the dangers of being a Lighthill. And Rick, Alfred
and Kung all were totally supportive during the day, although none got on their
soapbox the way Nico had an opportunity to do. So, I am a little unclear
about what it might mean to have a united front. We certainly shouldn't
jeopardize our chances of support in the other areas just ot have a schnit
about his attitudes about AI! What else did you have in mind?
11. All the above is built around a model of Jack as pretty reasonable and
knowledgable across much (of the rest) of computer science. With your
inclusion of talks with Bill Scherlis, it may be that you have a much wider
view than I do, and that Jack is thinking of doing crazy things in software or
in theory. It is certainly possible, although I don't have info on it.
12. I still think it remarkable that DARPA got a person of first rate
intellectual talents to be the next Director of ISTO and that we might have
gotten an industry-oriented guy from the weapons-systems world. (Recall Don
Hicks!) Thus, until I get more information, I am going to believe this guy is
on balance a good thing for the total field. Despite the troubles AI appears
to be in.
13. All that said, I am of course really pissed at this guy and his
intellectual arrogance. My back was doing pretty well. It has been giving me
cat fits this week end, and I suspect it is just my state of inner tension
about this whole thing. Grrrrrrrrrrr... I just want to take Soar and ram it
down his throat. To have him simply dismiss the chunking in Soar with all the
evidence we now have about it, with a remark such as "but what we need and
don't have is even one interesting idea about learning". Most of my private
thoughts about how to correct the situation center on how to structure the
situation so that I can change his mind. But I'm not bubbling over with good
ideas.
Cheers (sort of), AN
-------
-------
-------
∂06-Jan-88 0800 JMC
Texas bank
∂06-Jan-88 0900 JMC
Boucher
∂06-Jan-88 0900 JMC
question Blue Shield bill
∂06-Jan-88 1013 edsel!jlz@labrea.stanford.edu [jlz: ISO trip to Paris]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 10:13:00 PST
Received: by labrea.stanford.edu; Wed, 6 Jan 88 08:11:36 PST
Received: from sunvalleymall.lucid.com by edsel id AA19303g; Wed, 6 Jan 88 08:06:56 PST
Received: by sunvalleymall id AA17884g; Wed, 6 Jan 88 08:09:24 PST
Date: Wed, 6 Jan 88 08:09:24 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801061609.AA17884@sunvalleymall.lucid.com>
To: labrea!jmc%sail.stanford.edu@labrea.stanford.edu
Subject: [jlz: ISO trip to Paris]
John,
Dick asked that I contact you regarding the Paris ISO trip. Dick
would like the QLISP contract to pay both his and Will Clinger's
flight to and from Paris. DARPA has agreed, in principle, with
this arrangement. We need only to get your approval and I can
get the paper work rolling. I understand that we must use an
american carrier for DARPA to pay for this trip. We will make
sure all constraints are taken care of. My net address:
"edsel!jlz"@labrea
I hope to hear from you soon.
Thank you.
---jan---
∂06-Jan-88 1102 binford@anaconda welcome back
Received: from ANACONDA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 11:02:08 PST
Received: by anaconda (3.2/SMI-3.2)
id AA23352; Wed, 6 Jan 88 11:06:59 PST
Date: Wed, 6 Jan 88 11:06:59 PST
From: binford@anaconda (Tom Binford)
Message-Id: <8801061906.AA23352@anaconda>
To: jmc@sail
Subject: welcome back
John
Welcome back. Happy new year.
With fondest regards
Tom
∂06-Jan-88 1106 CLT two things
I don't recall paying any Menlo Medical Bills
recently, but I will have to look at the check book
and bills paid file to be sure.
Remind me tonight.
Also, Hazel said Mary Fisher called to
say we were invited to some sort of
`rest of christmas' party tonight.
You may go if you like, but I would rather not.
∂06-Jan-88 1113 CLT two things
ok, also on friday evening there is a party at Fefermans
for G. Longo. I think I will go over for a little while.
If your cong. dinner is over soon enough you could drop by.
∂06-Jan-88 1734 ME TAP account
To: TAP@SAIL.Stanford.EDU
CC: LES@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU,
JJW@SAIL.Stanford.EDU, ME@SAIL.Stanford.EDU, LMG@SAIL.Stanford.EDU
Pending a fix of a database program on Score, I've manually added
your name (Pat Simmons) into SAIL's list of authorized users. So
you should no longer get the "unknown" or "unauthorized" messages
from various programs like Login and Finger.
∂06-Jan-88 1921 Qlisp-mailer new-qlisp available
Received: from Gang-of-Four.Stanford.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 19:21:48 PST
Received: from labrea.stanford.edu by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02645; Wed, 6 Jan 88 19:23:29 pst
Received: by labrea.stanford.edu; Wed, 6 Jan 88 19:21:46 PST
Received: from bhopal.lucid.com by edsel id AA22230g; Wed, 6 Jan 88 19:15:58 PST
Received: by bhopal id AA14363g; Wed, 6 Jan 88 19:18:19 PST
Date: Wed, 6 Jan 88 19:18:19 PST
From: Ron Goldman <edsel!arg@labrea.stanford.edu>
Message-Id: <8801070318.AA14363@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp available
A new version of Qlisp is available in /lucid/bin/new-qlisp with two minor
changes as requested by Joe and Dan:
1) The function "make-lock" now expects the lock type to be specified as a
keyword. That is:
(make-lock :type :spin) ; make a spin lock
(make-lock :type :sleep) ; make a sleep lock
2) I just added a new version of the function "time" called "%time" that
doesn't print anything, but returns multiple values. The first value
returned is the value of the form that was being timed. If the form
returned multiple values, then they are made into a list. The second
value is the user cpu time. The third value is the system cpu time.
The fourth, and final, value is the elapsed time. For example:
> (time (fib 15))
Elapsed real time = 20 milliseconds
User cpu time = 22 milliseconds
System cpu time = 0 milliseconds
Total cpu time = 22 milliseconds
987
> (%time (fib 15))
987
22
0
20
> (%time (floor 5 4))
(1 1)
2
0
0
>
There is also a "%qtime" equivalent to (%time (qeval form))
3) There's also a minor fix to throw that should make it possible now to
abort back to Lisp top level if you enter the debugger from the idle job.
For example, all of your processes block, and you type a ↑C since nothing
seems to be happening, causing you to interrupt a process running the
idle job and cause it to enter the debugger --- now you can at least
get back to Lisp top level.
Ron
p.s. Coming soon: deep binding!
∂06-Jan-88 2116 RPG
∂02-Jan-88 1434 JMC
I'm back. Let's meet. How about Wednesday lunch?
I just got back today. How about friday or monday morning?
∂06-Jan-88 2153 RDZ@Score.Stanford.EDU Throop
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 21:53:05 PST
Date: Wed, 6 Jan 1988 21:51 PST
Message-ID: <RDZ.12364610116.BABYL@SCORE.STANFORD.EDU>
From: RDZ@Score.Stanford.EDU
To: jmc@Sail.Stanford.EDU
Subject: Throop
He sent me the missing file.
Ramin
∂06-Jan-88 2308 RFC Prancing Pony Bill
Prancing Pony bill of JMC John McCarthy 6 January 1988
Previous Balance 4.00
Monthly Interest at 1.0% 0.04
Current Charges 4.00 (bicycle lockers)
-------
TOTAL AMOUNT DUE 8.04
PAYMENT DELIVERY LOCATION: CSD Receptionist.
Make checks payable to: STANFORD UNIVERSITY.
Please deliver payments to the Computer Science Dept receptionist, Jacks Hall.
To ensure proper crediting, please include your PONY ACCOUNT NAME on your check.
Note: The recording of a payment takes up to three weeks after the payment is
made, but never beyond the next billing date. Please allow for this delay.
Bills are payable upon presentation. Interest of 1.0% per month will be
charged on balances remaining unpaid 25 days after bill date above.
An account with a credit balance earns interest of .33% per month,
based on the average daily balance.
You haven't paid your Pony bill since 11/87.
Accounts with balances remaining unpaid for more than 55 days are
considered delinquent and are subject to reduction of credit limit.
Please pay your bill and keep your account current.
∂07-Jan-88 0946 RPG Various topics
I would prefer some time like 9:00am or after 6:00pm on monday.
The weekend is generally ok for me too.
DARPA has tentatively approved spending QLISP travel money on
the ISO travel. We have a fair bit of that sort of money left over,
but we need your approval (a letter is ok) to use it for that
purpose. Could you write such a letter? I think Jan Zubkoff already
asker you about this.
-rpg-
∂07-Jan-88 1142 LIBRARY@Score.Stanford.EDU tech report overdue
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 11:42:39 PST
Date: Thu 7 Jan 88 11:07:47-PST
From: Math/Computer Science Library <LIBRARY@Score.Stanford.EDU>
Subject: tech report overdue
To: jmc@Sail.Stanford.EDU
cc: "*PS:<LIBRARY>OVERDUES..15"@Score.Stanford.EDU
Message-ID: <12364754996.24.LIBRARY@Score.Stanford.EDU>
STANFORD UNIVERSITY
MATH & COMPUTER SCIENCES LIBRARY
LIBRARY@SCORE
723-4672
_______________________________________________________________________________
DATE 1/7/88
CALL#: 024652 (technical report)
AUTHOR: Nelson and Oppen
TITLE: Simplification by cooperating design proceedings.
The above publication is overdue.
Renewable only in person with technical report.
Please renew or return this item. If we do not hear from you by 2/7/88 we
will proceed with a replacement bill.
-------
∂07-Jan-88 1339 @Score.Stanford.EDU,@RELAY.CS.NET:jamesp@BRANDEIS.CSNET Funds for Workshop proposal
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 13:38:57 PST
Received: from RELAY.CS.NET by SCORE.STANFORD.EDU with TCP; Thu 7 Jan 88 13:37:34-PST
Received: from relay2.cs.net by RELAY.CS.NET id ac13398; 7 Jan 88 16:32 EST
Received: from brandeis by csnet-relay.csnet id ab29207; 7 Jan 88 16:24 EST
Received: by brandeis.ARPA (5.51/4.7)
id AA12461; Thu, 7 Jan 88 11:43:40 EST
Date: Thu, 7 Jan 88 11:43:40 EST
From: James Pustejovsky <jamesp%brandeis.csnet@RELAY.CS.NET>
To: jmc%score.stanford.edu@RELAY.CS.NET
Subject: Funds for Workshop proposal
Cc: aaai-office%sumex-aim.stanford.edu@RELAY.CS.NET,
walker%flash.bellcore.com@RELAY.CS.NET,
jamesp%brandeis.csnet@RELAY.CS.NET
Dr. McCarthy,
Don Walker suggested that I contact your office.
I am attaching a proposal for a workshop to be held at Brandeis
University in the late spring of 1988.
A contribution of $5,000 from the AAAI would make this workshop
possible.
The model for this workshop is the one held this past summer at
Stanford during the linguistics institute.
Considerable progress has been made during the previous larger
workshops and, in particular, by the working group on syntax.
The proposed workshop will take as a starting point the progress
made this past summer in two of the working groups (Semantics and
Thematic/Case roles). Because of the specialized topic, this one will be on
a much smaller scale, involving no more than 15 people. If you wish,
I can provide you with a longer proposal and also send you more
detailed descriptions of the issues to be addressed. Please let me
know if there is any thing else you require in order to evaluate the proposal.
Thanks for you quick consideration.
James Pustejovsky
Assistant Professor of Computer Science
Brandeis University
THEORETICAL AND COMPUTATIONAL ISSUES IN LEXICAL SEMANTICS
A three-day intensive workshop held April 21-24, 1988, at Brandeis
University, in Computer Science.
This workshop will examine approaches to lexical semantics in
computational linguistics, knowledge representation, and linguistics
in order to establish what the necessary foundational concepts are in the
semantics of the lexicon. Most of the issues in syntactic form and
content for lexical entries have been adequately dealt with, yet what
has not been squarely addressed is the
status of lexical meaning in relation to the larger domain of commonsense
understanding of words.
We will explore and define the problems that are most central in
lexical semantics. There are essentially 4 problems we wish
to address:
1. What is the role of decomposition in the definition of lexical
entries for natural language systems and dictionaries? What is the
computational and representational trade-off between fixed semantic
roles (e.g. Case roles, (Fillmore, 1968), (Gruber, 1965))
and decomposition into primitives (cf. (Lakoff 1968, 1972),
(Wilks, 1975), (Schank, 1975, 1980), (Dowty, 1979))?
2. What information is part of the lexical entry and what
can be considered simply associative semantic information?
We will discuss approaches taken to commonsense reasoning about language, such
as that of (Hobbs et al, 1986) and (Dahlgren, 1986) and debate whether
there are separate levels of representation (the linguistic denotation
and a denotation in a model).
3. The third main topic to be addressed is that of the interface
between lexical semantics and syntactic projection, namely the
correspondence rules necessary to map the lexical information onto
syntactic representation.
4. Can we provide a coherent model for the semantic of nominals?
This has been a relatively neglected area in lexical semantics research, but
is important for representing relational nominals as well as the semantics of
nominal compounds, still a sore point in most NLU systems.
Participation will be primarily by invitation, although it is possible
to petition for inclusion. The workshop will be open to selected
graduate students who are willing to actively participate in the discussion.
A PARTIAL LIST OF LIKELY PARTICIPANTS
James Allen, University of Rochester
Emmon Bach, University of Massachusetts, Amherst
Kathleen Dahlgren, IBM Los Anglese Scientific Center
Robin Fawcett, UWIST, Cardiff, Wales
Charles Fillmore, University of California, Berkeley
Jerry Hobbs, SRI and CSLI
Ray Jackendoff, Brandeis University
Robert Ingria, BBN Laboratories
Judy Kegl, Princeton University
Beth Levin, Northwestern University
Martha Palmer, UNISYS
James Pustejovsky, Brandeis University
Len Talmy, University of California, Berkeley
John Sowa, IBM Systems Research Institute
Annie Zaenen, Xerox, PARC
Antonio Zampolli, Laboratorio di Linguistica Computazionale, Pisa, Italy
BUDGET
We expect to have between 12 and 15 participants. We would like to
provide travel and subsistence for about 10 invited people who do not
have adequate resources to cover their own expenses. The minimum
room costs for the three days should be about $150
(assuming university accommodations, which are reserved); meals will
average to $23.00 per person per day; travel costs should total no more
than $3000, since some participants have their own support.
EXPENSES
$ 1,500 Lodging for 10 participants @ $150
1,000 Meals and Reception
3,000 Travel
100 Photocopying
-------
$ 5,600 Total
INCOME
5,000 amount requested from AAAI
600 local univeristy support
-------
$ 5,600 Total
Submitted by
James Pustejovsky
Computer Science Department
Ford Hall
Brandeis University
Waltham, MA. 02254
617:736-2709
jamesp@brandeis.edu (csnet)
∂07-Jan-88 1402 VAL Nonmonotonic Reasoning Seminar: Correction and Reminder
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
Notice that the room number is different from the one given in the
first message.
FORMALIZING COMMONSENSE KNOWLEDGE
IN AUTOEPISTEMIC LOGIC
Michael Gelfond (UI00%UTEP.BITNET@WISCVM.WISC.EDU)
University of Texas at El Paso
Thursday, January 7, 4:15pm
MJH 352
In this talk we show how autoepistemic logic can be applied to
such seemingly different domains as deductive databases, taxonomic
hierarchies, and temporal reasoning. In particular, a new and very simple
formalization of the Yale shooting problem will be presented.
∂07-Jan-88 1538 LES Financial review
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
VAL@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU,
TAP@SAIL.Stanford.EDU
We need to review the financial state of our projects soon. I propose
2pm tomorrow (Friday) in JMC's office.
∂07-Jan-88 1813 CLT
ter Meulen, Alice (Dr. A.) 206-527-2996 (home) 206-543-4374 (1986 ofc)
C4731@UWAVM.ACS.WASHINGTON.edu
∂07-Jan-88 1944 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 19:44:39 PST
Date: Thu 7 Jan 88 19:41:46-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12364848562.12.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301 [bring-your-own-lunch style]
January 8: Dr. Vladimir Lifschitz (Stanford Univ.),
"Mathematical Models of Nonmonotonic Reasoning"
[NOTE: This first meeting will be for once in MJH 352!]
January 15: Dr. Natarajan Shankar (Stanford Univ.),
"Checking Proofs using the Boyer-Moore Theorem Prover"
-------
∂08-Jan-88 0103 ME failed mail returned
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 20:59:46 PST
Received: from Sail.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 7 Jan 88 20:59:36 PST
Date: Thu, 7 Jan 88 20:59:36 PST
From: Mail Delivery Subsystem <MAILER-DAEMON@labrea.stanford.edu>
Subject: Returned mail: Host unknown
To: <Mailer@sail.stanford.edu>
ME - The user address failed. The su-etc destination worked.
----- Transcript of session follows -----
bad system name: russell
uux failed. code 68
550 <russell!rustcat@LABREA.STANFORD.EDU>... Host unknown
----- Unsent message follows -----
Date: 07 Jan 88 2058 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: A saying
To: russell!rustcat@LABREA.STANFORD.EDU, su-etc@SAIL.Stanford.EDU
[In reply to message from russell!rustcat@labrea.stanford.edu sent Thu, 7 Jan 88 16:21:55 PST.]
"But for the grace of God there goes John Bradford."
John Bradford - 1510?-1555. Exclamation on seeing some
criminals taken to execution. Dict. of Nat. Biog.
as cited on Oxford Dictionary of Quotations, p. 79.
I would imagine "There but for the grace of God go I"
is the result of someone polishing the Bradford quotation.
∂08-Jan-88 0700 JMC
keyboard
∂08-Jan-88 0743 STEINBERGER@KL.SRI.COM re: quality TV
Received: from KL.SRI.COM by SAIL.STANFORD.EDU with TCP; 8 Jan 88 07:42:57 PST
Date: Fri 8 Jan 88 07:42:42-PST
From: Richard Steinberger <STEINBERGER@KL.SRI.COM>
Subject: re: quality TV
To: JMC@SAIL.STANFORD.EDU
cc: su-etc@SCORE.STANFORD.EDU, STEINBERGER@KL.SRI.COM
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 7 Jan 88 20:49:00-PST
Message-ID: <12364979805.20.STEINBERGER@KL.SRI.COM>
I believe that John McCarthy is misinterpreting my comments in regard to
"All in the Family." The fact that the show had a predominantly liberal
(circa 1970) viewpoint combined with the fact that I thought the show
presented issues that had up to then been too taboo for TV does not mean
that I did or do now accept the worldview of Norman Lear.
"All in the Family" was a watershed TV program not because of its
politics. If Norman Lear had been a Barry Goldwater supporter but allowed
his show to present racism, sexism, homophobia, ageism and other social
issues in a comic light, the show would have still, I maintain, been very
successful.
I rarely watch TV today. If there were more shows that had the insight
and daring of "All in the Family" I might be more of a couch potato.
-Ric S.
P.S. John, I guess Dragnet and the FBI were two of your favorites? %-)
-------
∂08-Jan-88 0917 VAL re: Financial review
[In reply to message rcvd 07-Jan-88 15:38-PT.]
The proposed time for the financial review meeting conflicts with your
meeting with Gelfond. How will we resolve it?
∂08-Jan-88 1008 CLT
The bath towel I gave sarah to use
is missing, so I assume she packed
it in her things. It was a plain grey
towel. Could you please ask her to
send it as soon as possible.
∂08-Jan-88 1112 MAYR@Score.Stanford.EDU workshop on pararllel computation
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 88 11:12:53 PST
Date: Fri 8 Jan 88 11:11:31-PST
From: Ernst W. Mayr <MAYR@Score.Stanford.EDU>
Subject: workshop on pararllel computation
To: cheriton@Score.Stanford.EDU, dek@Sail.Stanford.EDU,
goldberg@Navajo.Stanford.EDU, jmc@Sail.Stanford.EDU,
pratt@Score.Stanford.EDU, ullman@Navajo.Stanford.EDU
Message-ID: <12365017818.24.MAYR@Score.Stanford.EDU>
There is going to be a workshop on "Massively parallel models of computation"
at the Banff Spring Hotel, Banff, Canada, from March 13 - March 20. There
will be five lecturers each giving four or five one hour talks. They are
Chuck Seitz and Yasser Abu-Mostafa from Caltech, Lennart Johnson from Yale
and Thinking Machines, B. Ackland from Bell Labs, yours truly, and possibly
Carl Hewitt from MIT.
The total number of participants will be around 50, split equally between
Canada and this country. The organizers have asked me to name four or five
Stanford students to participate in the workshop. The cost per student is
a flat $1k.
Please let me know as soon as possible (early next week) whether you'd like
to nominate one of your students interested in parallel computation. If
you need more information I have a few more notes in my office, just come
by and ask.
-ernst
-------
∂08-Jan-88 1129 STAGER@Score.Stanford.EDU CS101 text
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 88 11:29:33 PST
Date: Fri 8 Jan 88 11:28:20-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: CS101 text
To: jmc@Sail.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12365020882.27.STAGER@Score.Stanford.EDU>
The Bookstore still hasn't been able to track down the "Fifth Generation
Computers" text you requested. They've notified the publisher (Ellis Horwood
Ltd. Halsted Press: A division of John Wiley and Sons) with no luck. The
publisher DOES have a text called "Fifth Generation Computers", but the
author is Bishop, not Barlow, Horwood. Could this be the text, or will
this remain a mystery? Looks like they have less than 100 copies of it
anyway.
What do you think?
Claire
-------
∂08-Jan-88 1236 SHOHAM@Score.Stanford.EDU mtg
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 88 12:36:05 PST
Date: Fri 8 Jan 88 12:34:41-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: mtg
To: nilsson@Score.Stanford.EDU, jmc@Sail.Stanford.EDU,
feigenbaum@SUMEX-AIM.Stanford.EDU, winograd@CSLI.Stanford.EDU,
zm@Sail.Stanford.EDU, shortliffe@SUMEX-AIM.Stanford.EDU,
buchanan@SUMEX-AIM.Stanford.EDU, genesereth@Score.Stanford.EDU,
latombe@Whitney.Stanford.EDU, binford@Whitney.Stanford.EDU,
tenenbaum@SPAR-20.SPAR.SLB.COM, clancey@SUMEX-AIM.Stanford.EDU,
shoham@Score.Stanford.EDU, weise@Mojave.Stanford.EDU,
reges@Score.Stanford.EDU, snow@Sushi.Stanford.EDU
Message-ID: <12365032958.29.SHOHAM@Score.Stanford.EDU>
Thanks for attending the meeting, those who did (which is almost
everyone). I'll help Stuart draft some straw man. In the meanwhile some
of you may have further suggestions, which will be cherished.
Yoav
-------
∂08-Jan-88 1633 STAGER@Score.Stanford.EDU Paul Haley
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Jan 88 16:33:52 PST
Date: Fri 8 Jan 88 16:27:23-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Paul Haley
To: jmc@Sail.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12365075320.32.STAGER@Score.Stanford.EDU>
Do you have a phone number or email address where I can get in touch with
Paul Haley? We need to pin down a time for next quarter's CS309C (by end
of the day Monday if it's to make it into the University's time schedule
booklet).
Thanks.
Claire
-------
∂08-Jan-88 1650 RPG Qlisp
To: JMC, LES
Unless we get that extension by January 15, we cannot bill starting
then, which means we'll have to drop the work, I guess.
-rpg-
∂08-Jan-88 1658 RPG Meeting
9am monday.
∂08-Jan-88 1658 croft@russell.stanford.edu your russell account
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jan 88 16:58:49 PST
Received: by russell.stanford.edu (3.2/4.7); Fri, 8 Jan 88 17:01:58 PST
Date: Fri, 8 Jan 88 17:01:58 PST
From: croft@russell.stanford.edu (Bill Croft)
To: jmc@sail
Subject: your russell account
John, your account is now named jmc instead of johnmc.
∂09-Jan-88 0947 RPG Qlisp Situation
To: JMC
CC: rpg-q
I spoke to Scherlis last night. He was distressed by the situation
but thought it could be fixed quickly if we act quickly.
First, we should call Paul Chock and find out whether he can
begin to act before any paperwork arrives. We should get him up to
date on the rest of our actions to straighten this out.
Second, we should call Tice DeYoung at SPAWAR, who is Pucci's boss, and
explain what happened. We should say that because of personnel shuffling
at Lucid we underran by some $250k and that we want a no-cost,
no-additional-task extension to complete the work, using that money. His
number is (202)692-3966. Also ask him whether he can begin to act before
he gets any paperwork from Stanford, Lucid, or DARPA. We should explain
we've talked to Scherlis. If he is not at that number, we should ask if he
is at DARPA and then to call Scherlis' number at DARPA and find DeYoung
there.
If DeYoung is not available, we should try John Pucci at (202)692-9207.
Third, to get the second 18 months, we should send a 1-page summary of
what we've done and what we want to do. This should be in bulletized
format. Of importance to DARPA is the availability of Qlisp to other
groups and the potential for Qlisp to become a resource to the community.
Scherlis has pushed Encore to deal with Lucid and Qlisp, and that
relationship has now started, so we can use that. Apparently Encore
has good currency these days at DARPA.
That summary should be netmailed to Squires and cc'ed to Scherlis.
Scherlis was concerned that the tasking contract at Stanford might
not provide for a second 18 months, but I'm pretty sure we set it
up that way. He said if it is, then another 18 months is a good
bet, and they can get it done in about 1 month.
On a related topic, he is concerned that CSD is dropping the ball with
DARPA funding. He is concerned that the faculty cannot work together to
propose coherently and that the tasking contract is not being utilized
effectively. Though he didn't say it, I got the impression that funding
from DARPA to CSD could be in short supply unless this situation is not
fixed. Possibly I should meet with Nils to discuss this.
-rpg-
∂10-Jan-88 1650 ME new login name for Pat Simmons
To: "#MSG.MSG[1,TAP]"
CC: CLT, JMC, LES, JJW, RWF, ME
Pat,
Your account name has been changed from TAP to MPS. So please log out
now (you're logged in under the old name TAP), and log back in under MPS.
All your files have been moved to corresponding new MPS directories.
The passwords for MPS are the same as they were for TAP. Mail for TAP
is forwarded to MPS for now, in case anyone forgets (or doesn't know)
your new name.
-- Martin
∂10-Jan-88 2010 Qlisp-mailer TAK times
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 88 20:10:40 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA07057; Sun, 10 Jan 88 20:12:16 pst
Date: Sun, 10 Jan 88 20:12:16 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8801110412.AA07057@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: TAK times
Running the TAK benchmark on the N stack scheduler gives times of
roughly .22 seconds. It ran as fast as 199 milliseconds and as slow
as 265 milliseconds. The variance in times is somewhat disconcerting,
but the speed achieved is quite respectable. According to RPG's
book, a time of .22 on TAK is faster than any (then) existing "full"
lisp system. In serial, the TAK benchmark runs in about .66 seconds.
The code:
(defun tak (x y z)
(if (not (< y x))
z
(qlet (qempty)
((a (tak (1- x) y z))
(b (tak (1- y) z x))
(c (tak (1- z) x y)))
(tak a b c))))
(tak 18 12 6)
The speed-up is roughly 3 out of a possible 4, and
gets better for larger x y and z. For (tak 20 12 4)
the best parallel time was 7.08 seconds and serial
was 26.05 seconds, for a speed-up of 3.7 out of 4.
-dan
∂10-Jan-88 2115 RWW the origin of the name LISP
What can you tell me about the origin of the name. I am translating
a Japanese book by Yuasa and his ideas are certainly not true.
Thanks. (By the way welcome back)
Richard
∂11-Jan-88 0045 RWW thanks
∂11-Jan-88 0257 LES Post-mortem
As I remarked in our last discussion, I fully understand your feeling that
I should go away and I am planning to comply. I would like to briefly
review here what happened, inasmuch as I am still trying to understand it
myself. These remarks not offered as an excuse for what happened, just an
explanation.
Both before and after my return to Stanford, I thought I did a reasonable
job of assembling proposals for you (QLISP and others), shepherding them
through the bureaucracy, negotiating details with the sponsors and
subcontractors, and procuring needed equipment and services. I also took
on the responsibility for the department of figuring out how to usefully
spend the residual DARPA equipment funds and did that well, I believe.
I too was disappointed with how the EBOS project developed (or didn't).
Initially, I thought that you and I were talking about the same thing,
inasmuch as we were using some of the same words, but I later learned that
you had a different agenda (which I never fully understood) and were not
much interested in my agenda.
My ideas revolved around an editor that would work with large symbol
sets to create text and graphics. It would be used to create documents,
control processes, and display both outputs and process connectivity and
status. I also had an idea for a novel keyboard design that I would still
like to pursue, and plan do so at the earliest opportunity.
Anyway, you weren't buying what I was selling and I couldn't understand
just where you were headed, so I encouraged Greep to try to connect with
your interests. That attempt also failed, which shook up Greep quite a
lot; he retreated to LOTS and shortly left Stanford. Finally, Arkady
appeared and apparently established some kind of rapport with you. I was
happy that the project was finally apparently going somewhere; meanwhile I
was drawn into other activities.
When Nils asked me to take on additional departmental responsibilities,
I was a bit reluctant, but because of my admiration for him and the
job he was doing, I agreed to do it half-time for two years, possibly
renewable by mutual agreement.
Shortly after that, I discovered the Bosack/cisco mess. After some
investigating, I precipitated Len's departure, then set about cleaning up
the financial disaster that he had left in CSD-CF. I also worked hard at
coercing cisco into licensing the designs that they had stolen. This
was all rather depressing, as Bosack repeatedly lied about what had
happened and attempted other deceptions. It is only just now concluded.
The most depressing thing that I learned from all this was that crime pays.
After stealing $28,000 cash, assorted hardware designs, and a lot of
software, and using these things to found a company and run it from the
basement of Jacks Hall, while pretending to work for Stanford, the only
penalty when he got caught was having to repay the money a year and a half
later and agreeing to pay royalties that were probably a bit less than if
he had licensed these materials from the beginning.
Further complicating this mess was that my attempts to find a new Director
for CSD-CF ran aground when the prime candidate repeatedly asked for more
time to make a decision, then declined shortly after the only other
acceptable candidate took another job. Then the renewed search bogged
down over a posting problem. Anyway, that is all water over the dam.
Looking back, I think that I was beginning to burn out in this period.
While I think that I did a reasonable job of running CSD-CF (certainly
better than my immediate predecessor), it was not my idea of a great
paypen. Meanwhile, I didn't have many spare cycles to apply to other
departmental projects for Nils. I was determined to fulfill my two year
committment to him, but was beginning to think that I wasn't cut out for
the job.
The massive staff departures last summer convinced Nils that it was time
to reorganized the staff and he asked me to take on full time responsibilities
for the department. After thinking about it briefly, I said that I thought
he should find somebody else. I assumed that there was still room for me
in your projects, but I didn't discuss this point much with you nor did
we discuss what you would expect out of me. Under hindsight, this was
probably a mistake on my part.
Meanwhile, Nils made it clear that he was quite disappointed with my
decision not to go full time and began to systematically exclude me from
administrative responsibilities. I was already feeling guilty about
declining the offer; this development gave me a sense of failure of a sort
I have experienced only once or twice before in my life. My reaction to
it was something that I have never experienced before.
I didn't understand what was happening at the time, but my productivity
approached zero. Looking back, I realize that I had somehow slipped into
a deep depression. I knew that I was very uncomfortable but didn't know
what to do about it, having experienced only excellent physical and mental
health all my life till now.
Nobody around me seemed to notice what had happened. Some commented on
the fact that I had started playing Spider a great deal, but that is not
considered to be terribly bizarre hereabouts. I noticed that time started
lurching -- I would look at my watch, then what seemed like a few minutes
later I would discover that over three hours had passed, but I couldn't
remember having done anything in the meantime. I started skipping meals.
Instead of going home for dinner, I would stay at the terminal doing
useless things till two, three, or four in the morning. My wife understood
that something was wrong, but I seldom saw her and couldn't talk about it.
I remained in a semi-catatonic state for several months. I remember very
little that has happened since September. When people asked me questions,
I could respond in an apparently normal way, but I was otherwise mostly
nonfunctional except for occasional spurts of activity on things that had
nothing to do with work. I did ask Lucid for a proposal once or twice,
as I recall, but I don't think that I pressed them at all. According to
my notes, I tried to get Squires a couple of times, but missed and he didn't
return the calls.
As recently as Christmas, I couldn't face visiting my parents, with whom I
have always had good relations. Joan made the trip and apologized,
telling them that I was too busy to come. I stayed home and played Spider.
I now seem to be mending, though I feel as though I am functioning at only
about 25% of capacity. If this ever happens again, I probably will figure
it out sooner. I wish that someone had noticed what was happening and
kicked my butt, turned me upside down, or injected appropriate vitamins.
This has been a perlexing and embarrassing experience for me. Please
understand that I have the greatest respect and admiration for you and
would never purposely set you up for a fall.
The Qlisp funding situation is clearly very tight but not necessarily
irretrievable. I will do everything that I can to straighten it out in
the time remaining.
∂11-Jan-88 0830 STAGER@Score.Stanford.EDU re: Paul Haley
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 08:30:48 PST
Date: Mon 11 Jan 88 08:26:27-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: re: Paul Haley
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 8 Jan 88 16:46:00-PST
Office: CS-TAC 29, 723-6094
Message-ID: <12365774203.26.STAGER@Score.Stanford.EDU>
Thanks for the address and phone number.
Claire
-------
∂11-Jan-88 1002 Qlisp-mailer Schedulers
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 09:58:57 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA07894; Mon, 11 Jan 88 10:00:32 pst
Date: Mon, 11 Jan 88 10:00:32 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8801111800.AA07894@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Schedulers
The times which I have been posting to Qlisp all use Nsched, a
scheduler first developed on Csim (the simulator) and then
reimplemented in Qlisp. It is currently distinct from the scheduler
provided with the Qlisp system. It has been suggested that Nsched
should be compared with the scheduler that boots up with Qlisp. For
several reasons, I have avoided doing this comparison. Mainly, I
figured it was a prototype, to be replaced soon by a real scheduler.
I thought it unfair to make comparisons. But it is now appropriate to
make comparisons. All times are in milliseconds and were the min of 5
runs.
Test Nsched Serial Qlisp
(fib 5) 2 0 6
(fib 10) 4 2 33
(fib 15) 14 25 506
(fib 20) 98 274 n.a.
(fib 25) 912 3036 n.a.
(fib 30) 9577 30150 n.a.
(tak 8 6 4) 4 1 13
(tak 9 6 3) 8 3 41
(tak 10 6 2) 15 19 313
(tak 11 6 1) 54 112 n.a.
(tak 12 6 0) 219 685 n.a.
(tak 13 6 -1) 1206 4265 n.a.
The n.a. means Qlisp breaks on the given test, usually because it
ran out of stack space.
-dan
∂11-Jan-88 1240 AI.THROOP@R20.UTEXAS.EDU
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:40:43 PST
Date: Mon 11 Jan 88 14:39:08-CST
From: David Throop <AI.THROOP@R20.UTEXAS.EDU>
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 11 Jan 88 11:43:00-CST
Message-ID: <12365820200.40.AI.THROOP@R20.UTEXAS.EDU>
How about:
tonight at 8pm Austin time (6 pm Palo Alto time) at
(512) 453 8032 (home no.)
or you can try me at (512) 471 9559 through about 4:30 Austin time (2:30
PA) (lab no.)
David
-------
∂11-Jan-88 1423 PHY
To: "@THEORY.DIS[1,PHY]"@SAIL.Stanford.EDU
Don Knuth would like the senior members of the Theory Group of Computer
Science to meet for lunch at the Faculty Club next Monday, January 18.
Please let me know ASAP so that I can make the reservations.
- Phyllis
∂11-Jan-88 1428 helen@psych.Stanford.EDU Re: lunch
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 14:28:46 PST
Received: by psych.Stanford.EDU (3.2/4.7); Mon, 11 Jan 88 14:26:45 PST
Date: Mon, 11 Jan 88 14:26:45 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: lunch
Cc: helen@psych.Stanford.EDU
Hello there,
Lunch, definitely. But this week is REALLY bad for me. How about
next week? Any day should be fine. Let me know.
-helen
∂11-Jan-88 1441 Qlisp-mailer Qlisp bug warning
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 14:41:34 PST
Received: from labrea.stanford.edu by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08574; Mon, 11 Jan 88 14:43:13 pst
Received: by labrea.stanford.edu; Mon, 11 Jan 88 14:41:31 PST
Received: from bhopal.lucid.com by edsel id AA20473g; Mon, 11 Jan 88 14:35:13 PST
Received: by bhopal id AA08425g; Mon, 11 Jan 88 14:37:56 PST
Date: Mon, 11 Jan 88 14:37:56 PST
From: Ron Goldman <edsel!arg@labrea.stanford.edu>
Message-Id: <8801112237.AA08425@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Qlisp bug warning
Be forewarned, if you do bignum arithmetic in Qlisp you may hit a bug.
There is an internal resource that is used to allocate temporary bignums, and
it is not set up to run in a multiprocessing world. If you have several
processes that simultaneously do bignum arithmetic then you might run into
this bug. There are almost certainly a whole bunch of similar resource
related bugs lurking in Qlisp just waiting to strike. We'll be ferreting
them out, starting in a few weeks. Hopefully we'll fix them before you
find them.
Ron
∂11-Jan-88 1503 helen@psych.Stanford.EDU re: lunch
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 15:03:35 PST
Received: by psych.Stanford.EDU (3.2/4.7); Mon, 11 Jan 88 15:01:35 PST
Date: Mon, 11 Jan 88 15:01:35 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: lunch
Cc: helen@psych.Stanford.EDU
Ok, sounds great! Thursday Jan 21, noon at Faculty Club.
I think I'll be able to find you. I'm a bit less "descript"
but will wear a blue-green silk scarf. How's that? See you
there and then.
-helen
∂11-Jan-88 1610 BALDWIN@Score.Stanford.EDU free baby gates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 16:10:34 PST
Date: Mon 11 Jan 88 12:24:04-PST
From: Julie Baldwin <BALDWIN@Score.Stanford.EDU>
Subject: free baby gates
To: jmc@Sail.Stanford.EDU
Message-ID: <12365817458.13.BALDWIN@Score.Stanford.EDU>
where?
-------
∂11-Jan-88 1700 @Score.Stanford.EDU:CLANCEY@SUMEX-AIM.Stanford.EDU [Bill Mann <MANN@venera.isi.edu>: [Bill Mann <MANN@VENERA.ISI.EDU>: AAAI -- Workshop proposal: 4th In]]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 17:00:15 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 16:02:32-PST
Date: Mon, 11 Jan 88 16:03:13 PST
From: William J. Clancey <CLANCEY@SUMEX-AIM.Stanford.EDU>
Subject: [Bill Mann <MANN@venera.isi.edu>: [Bill Mann <MANN@VENERA.ISI.EDU>: AAAI -- Workshop proposal: 4th In]]
To: mccarthy@score.Stanford.EDU
Message-ID: <12365857353.77.CLANCEY@SUMEX-AIM.Stanford.EDU>
Return-Path: <mann@venera.isi.edu>
Received: from venera.isi.edu by SUMEX-AIM.Stanford.EDU with TCP; Mon, 11 Jan 88 14:33:46 PST
Posted-Date: Mon 11 Jan 88 14:34:10-PST
Received: by venera.isi.edu (5.54/5.51)
id AA20880; Mon, 11 Jan 88 14:34:12 PST
Date: Mon 11 Jan 88 14:34:10-PST
From: Bill Mann <MANN@venera.isi.edu>
Subject: [Bill Mann <MANN@VENERA.ISI.EDU>: AAAI -- Workshop proposal: 4th In]
To: clancey@sumex-aim.stanford.edu
Message-Id: <568938850.0.MANN@VENERA.ISI.EDU>
Mail-System-Version: <VAX-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
Bill:
Could you do me the favor of forwarding this to John McCarthy? Numerous
tries at constructing his net address here have failed.
Thanks.
Bill Mann
---------------
Date: Mon 11 Jan 88 14:30:51-PST
From: Bill Mann <MANN@VENERA.ISI.EDU>
Subject: AAAI -- Workshop proposal: 4th Intl on NL Generation
To: mccarthy@SUMEX-AIM.STANFORD.EDU
Message-ID: <568938651.0.MANN@VENERA.ISI.EDU>
Mail-System-Version: <VAX-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
John,
Below there is a proposal for a workshop to be held this summer.
It is part of an established series in computational linguistics. These
workshops are contributing to significant progress in establishing an
appropriate theoretical basis for natural language generation. $5,000
from the AAAI would make a significant difference.
Please let me know what additional information you need for
evaluation. (A paper copy of the proposal will also be sent.)
Bill Mann
................................................................
Fourth International Workshop on Natural Language Generation
OVERVIEW
There have been three previous international workshops on natural
language generation, in 1983, 1984 and 1986. The subject matter is part of
both linguistics and computer science. Each workshop has been independent,
organized by an ad hoc committee. The Fourth International Workshop on Natural
Language Generation will be held July 20 - 22, 1988, under the informal
supervision of a workshop committee drawn from the research staff of the
University of Southern California, Information Sciences Institute. Support is
needed for travel expenses and workshop expenses.
The Fourth Workshop is expected to attract the best researchers of the
field, serve as a vehicle for distribution of unique new tools, promote
significant sharing of new ideas, provide a means of cross-communication
between the "text generation" and "explanation" factions of the community, and
to produce an edited book representative of the current state of the art.
1 Natural Language Generation
Natural Language Generation is the synthesis of communications in human
languages. It has developed, primarily in the last 10 years, as a distinct
technical focus in artificial intelligence (within computer science) and in
linguistics. There is a growing literature, and there are several universities
granting PhDs based on dissertations in the area. The area is distinct from
natural language understanding, an older line of specialization, with very
different problems and accomplishments.
2 Previous Workshops
The first workshop was organized by Dr. Joachim Laubsch to coincide with
the 1983 IJCAI conference, and held at University of Stuttgart. The second was
organized by Dr. Douglas Appelt and Dr. Ivan Sag, and held at Stanford
University in coincidence with the 1984 Coling and ACL conference.
The Third International Workshop on Natural Language Generation was
organized by Dr. Gerard Kempen and held at the University of Nijmegen, The
Netherlands. It convened a group of internationally recognized researchers for
3 days at a hotel near the University of Nijmegen. There were 29 presented
papers, as well as more informal discussions. The papers have already appeared
in a book [Kempen 86]:
Natural Language Generation: New Results in Artificial Intelligence,
Psychology and Linguistics, Gerard Kempen, Editor, Martinus Nijhoff
Publishers, Dordrecht/Boston/Lancaster, 1987, 466 pages.
Based on recent experience, we expect to have no difficulty in again
turning the workshop proceedings into an edited book, for which the organizing
committee will serve as editors.
These workshops have been unique in attracting the best researchers of
the field. There have been no other occasional workshops, workshop series or
conferences that have attracted any comparable number of Natural Language
Generation researchers.
At the Third Workshop, researchers agreed that a 2-year interval between
workshops is appropriate. Since that time, there have already been more than
enough new ideas to justify another workshop. In addition, new tools have
emerged: two of the research organizations have prepared large computer
programs for generation, which are now ready for circulation in the field. The
workshop is expected to be the vehicle for their wide distribution.
Since the field is expanding, communication channels among researchers
are not well established. Rapid communication is particularly important in
this growth phase in order to avoid fragmentation.
The Fourth Workshop will be especially designed to foster interaction
between two subcommunities of research, informally identified as "text
generation" and "explanation." These subcommunities have shared many problems
and some subject matter, and are distinct mostly for historical reasons. A
specific goal for this workshop will be to attempt to bridge the gap between
those researchers concerned with the process of natural language generation
itself and those concerned with the knowledge representations needed to support
generation. We regard this sharing as particularly important at this time to
prevent research duplication and meaningless divergence.
3 The Workshop Organization and Plan
3.1 Committee
The organizing committee for the Fourth Workshop consists of:
* Dr. William C. Mann -- Dr. Mann has led natural language generation
research at ISI since 1979. He currently leads a team of 6
researchers in this area. Dr. Mann is one of the originators of
Rhetorical Structure Theory, a technical approach to discourse
description and construction.
* Dr. Cecile L. Paris -- Dr. Paris recently graduated from Columbia
University. Her PhD dissertation was entitled "The Use of Explicit
User Models in Text Generation: Tailoring to a User's Level of
Expertise."
* Dr. William R. Swartout -- Dr. Swartout has led research on natural
language generation and explanation technology at ISI since 1981.
His PhD dissertation at MIT was entitled "Producing Explanations and
Justifications of Expert Consulting Programs."
Both Swartout and Mann were contributors to a published 1981 survey of
natural language generation technology [Mann et. al. 82].
3.2 Workshop Plan
The workshop plan follows that of the Third Workshop. Attendance will be
by invitation. Attendees are invited but not required to submit a paper for
presentation.
In addition to presentation and discussion of papers, there will be
small-goup discussions, some of which will center on the relationship between
"explanation" and "text generation," one of the workshop themes.
The workshop attendees have already been identified and notified. A
partial list of invitees, nearly complete, is the following:
Name Present and/or Recent Affiliation
Appelt, Doug SRI International
Bateman, John USC/ISI and Kyoto University
Bock, Kathryn Michigan State University
Bunt, Harry University of Tilburg
Clancey, William Stanford University
Danlos, Laurence Universite de Paris
De Smedt, Koenraad University of Nijmegen
Ehrich, Veronika Max Planck ... Psycholinguistics
Hovy, Eduard USC/ISI and Yale University
Jameson, Anthony University of Nijmegen
Joshi, Aravind University of Pennsylvania
Haimowitz, Ira MIT
Kempen, Gerard University of Nijmegen
Kittridge, Richard University of Montreal
Kukich, Karen Bell Laboratories
Langlotz, Curt Stanford University Medical Center
Laubsch, Joachim Hewlett-Packard Computer Research Ctr.
Levelt, Willem Max Planck ... Psycholinguistics
Mann, William USC/ISI
Matthiessen, Christian USC/ISI and University of Sydney
McCoy, Kathleen University of Delaware
McDonald, David UMASS Amherst
McKeown, Kathleen Columbia University
Meteer, Marie UMASS Amherst and BBN
Moore, Johanna USC/ISI and UCLA
Nirenberg, Sergei Carnegie-Mellon University
Novak, Hans-Joachim IBM Deutschland GmbH
Paris, Cecile USC/ISI and Columbia University
Patten, Terry University of Edinburgh
Reithinger, Norbert Universitat des Saarlandes
Ritchie, Graeme University of Edinburgh
Roesner, Dietmar Universitat Stuttgart
Shieber, Stuart SRI International
Sigurd, Bengt Lund University
Sparck-Jones, Karen Cambridge University
Swartout, William USC/ISI
Thompson, Sandra UCLA and UC Santa Barbara
Webber, Bonnie University of Pennsylvania
Yazdani, Masoud University of Exeter
The workshop will span 3 days, and will be held at a resort hotel, not
yet selected, near Los Angeles, California.
3.3 Financial Support Plan
In order to make this an effective international workshop, we must
provide substantial support to participants. Universities and other research
institutions in many countries do not traditionally pay full expenses for this
kind of workshop.
Based on estimates of available funds, we are requesting that AAAI
provide a grant $5000. If the workshop is oversupported, the excess money will
be returned to supporters, beginning with the technical societies. No money
will be retained for future workshops.
Support is being sought primarily for attendees' expenses. Less than
$1000 is budgeted for workshop communications and other organizational
expenses. USC is providing secretarial support and the services of the
Workshop Committee at no charge. USC will also provide basic financial
services (such as accounting, receiving and disbursing workshop funds) but will
not be providing a grant of funds.
Participants have been offered partial support of their expenses on a
funds-available basis.
4 Budget
Grants are being sought from technical societies, and also from the
National Science Foundation and NATO. The technical societies include AAAI,
ACL, and ACM's Sigart.
Participants are requested to pay their expenses from other sources if
possible. There will be a workshop registration fee.
In order to provide for hotel deposits and final bill paying, spending
authority should begin May 1, 1988 and terminate September 30, 1988.
4.1 Expenditures
The amounts below are the portions projected as in need of support, not
the total cost of the workshop.
Air Fares: $12000
Hotel Room Charges: 4800
Meals: 3300
Hotel Facilities not included in room charges 0
Group transportation 500
Secretarial Services (provided at no charge by USC/ISI)
Communications 200
TOTAL: 20800
4.2 Projected Income
AAAI: 5000
Other Sources: 12200
Registration Fees: 3600
TOTAL: $20800
REFERENCES
[Kempen 86] Kempen, Gerard, (ed.), Natural Language Generation: New results
in Artificial Intelligence, Psychology and Linguistics, Martinus Nijhoff,
Dordrecht, The Netherlands, 1986. Proceedings of the Third International
Workshop on Text Generation
[Mann et. al. 82] Mann, W. C., et al., "Text Generation," American Journal of
Computational Linguistics 8, (2), April-June 1982, 62-69.
Submitted by:
William C. Mann
USC/ISI
4676 Admiralty Way,
Marina del Rey, CA 90292.
Arpanet: mann@venera.isi.edu
-------
-------
-------
∂11-Jan-88 1804 Qlisp-mailer new qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 18:03:57 PST
Received: from labrea.stanford.edu by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA09362; Mon, 11 Jan 88 18:05:33 pst
Received: by labrea.stanford.edu; Mon, 11 Jan 88 18:04:00 PST
Received: from bhopal.lucid.com by edsel id AA21816g; Mon, 11 Jan 88 17:57:31 PST
Received: by bhopal id AA09407g; Mon, 11 Jan 88 18:00:13 PST
Date: Mon, 11 Jan 88 18:00:13 PST
From: Ron Goldman <edsel!arg@labrea.stanford.edu>
Message-Id: <8801120200.AA09407@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new qlisp
A preliminary version of Qlisp that supports deep binding is now available.
It is /lucid/bin/new-qlisp. The old version of new-qlisp is now qlisp, and
the old qlisp is now old-qlisp. As always you need to recompile your
programs for them to work in the newer & better versions of Qlisp.
Ron
∂12-Jan-88 0910 GOODMAN%uamis@rvax.ccit.arizona.edu slight change of arpanet address
Received: from rvax.ccit.arizona.edu by SAIL.Stanford.EDU with TCP; 12 Jan 88 09:10:25 PST
Date: Tue, 12 Jan 88 09:17 MST
From: GOODMAN%uamis@rvax.ccit.arizona.edu
Subject: slight change of arpanet address
To: DUANE.ADAMS@c.cs.cmu.edu, BLUMENTHAL@a.isi.edu, DONGARRA@anl-mcs.arpa,
GANNON%RDVAX.DEC@decwrl.dec.com, JAHIR@athena.mit.edu, HEARN@rand-unix.arpa,
JLH@sierra.stanford.edu, JMC@sail.stanford.edu, MCHENRY@GUVAX.BITNET,
OUSTER@ginger.berkeley.edu, Ralston@mcc.com, CWEISSMAN@dockmaster.arpa
X-VMS-To: @NAS
From: UAMIS::JMS "Looking smart is no substitute for being smart." 8-JAN-1988 16:34
To: SALTZMAN,GOODMAN
Subj: your network address
is now user@mis.arizona.edu, not @mrsvax.mis.arizona.edu
jms
∂12-Jan-88 0910 MPS packages from texas
They sent 3 boxes, first class, by U.S. mail
on the 5th of January. I will contact her
at the end of the week if they haven`t arrived.
pat
∂12-Jan-88 0920 HART@KL.SRI.COM
Received: from KL.SRI.COM by SAIL.Stanford.EDU with TCP; 12 Jan 88 09:20:10 PST
Date: Tue 12 Jan 88 09:19:47-PST
From: Peter Hart <HART@KL.SRI.COM>
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 11 Jan 88 17:18:00-PST
Message-ID: <12366046056.33.HART@KL.SRI.COM>
Your msg reached me, although I believe the fully qualified host
name is KL.SRI.COM. --Peter
-------
∂12-Jan-88 0958 BALDWIN@Score.Stanford.EDU re: free baby gates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 09:58:22 PST
Date: Tue 12 Jan 88 09:57:03-PST
From: Julie Baldwin <BALDWIN@Score.Stanford.EDU>
Subject: re: free baby gates
To: JMC@Sail.Stanford.EDU
cc: CLT@Sail.Stanford.EDU, BALDWIN@Score.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 11 Jan 88 17:38:00-PST
Message-ID: <12366052839.31.BALDWIN@Score.Stanford.EDU>
I do want them. How many do you have?
-------
∂12-Jan-88 1011 BSCOTT@Score.Stanford.EDU CSD-CF, Qlisp Project
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 10:11:11 PST
Date: Tue 12 Jan 88 10:09:47-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: CSD-CF, Qlisp Project
To: JMC@Sail.Stanford.EDU
cc: LES@Sail.Stanford.EDU, CLT@Sail.Stanford.EDU, BScott@Score.Stanford.EDU
Message-ID: <12366055156.18.BSCOTT@Score.Stanford.EDU>
Your CSD-CF charges on this contract are running about $11,500/month. This
may be o.k., but want to call it to your attention.
Betty
-------
∂12-Jan-88 1038 MPS scheduling
Paul Haley (412-931-7600) called. He would like you
to call. He wants to schedule his AI lecture.
Pat
∂12-Jan-88 1057 Qlisp-mailer meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 10:57:27 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00873; Tue, 12 Jan 88 10:58:56 pst
Date: Tue, 12 Jan 88 10:58:56 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801121858.AA00873@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: meeting
The next qlisp meeting will be provisionally schedulled for 2pm on
thursday the fourteenth of January in MJH352. On the agenda will be
The State of The World.
∂12-Jan-88 1129 RPG Center
Well, I actually wrote that document but hestitated to send it
until my situation was truly known to myself. Here is what I
wrote the week before Thanksgiving:
Proposal for:
Center for Advanced Software
The purpose of the Center is to advance the state of software, software
development, programming languages, and programming environments.
As such, the work at the Center will focus on new programming languages
and programming paradigms, new operating systems, and user/programmer/program
interface technology.
Because powerful hardware is now truly available, the assumptions under
which current software is built are no longer valid. These assumptions are
based on the fact that the size and speed of computers were such that the
amount of work that the ``system'' performed for the user/programmer had
to be limited. Sufficiently powerful hardware to justify a rejection of
these assumptions has been available, at some cost, for many years; the
difference today is that sufficiently powerful hardware is now available
to the individual at low cost.
Parallel computers are also becoming more common. Programming languages and
programming systems for them are based on increments over older, serial
languages and systems. Few major efforts at a top-to-bottom approach to
parallel computing have been mounted.
At the Center we will work on these problems.
Organization
The Center is to be funded by a combination of the usual government
and non-government funding agencies. The Center will be an international
center, encouraging visitors from abroad and accepting funds from
foreign companies and governments. In addition, subscriptions from
companies will be accepted; these funds will accepted either into the
general funds of the Center or used to perform specific projects. All work
at the Center will be in the public domain.
Because the Center will be focussed on producing prototypes as well
as research papers, the staff will be a mixture of researchers,
professional programmers, and students.
If the Center is established as part of CIS, it will be an independent
entity in that it will control its own internal organization and
attract its own funding.
The size of the Center will be at most 10 researchers and
programmers at the start, growing to a maximum of 25 people after two
years. A realistic estimate of the initial size is 7 people.
Funding
First, the Qlisp project will be moved to the Center. This involves
moving the people from Lucid working on the project as well as the funding
to Lucid. The Stanford portion of the project will also move to the Center.
The funding for this project ought to support 5 or 6 people full time
and an extension of the contract for 1.5 - 2 more years (until 1990) is
expected. Several companies have expressed an interest in Qlisp, and
funding from those groups to supplement the DARPA money will be
obtained.
Second, the Center will propose to a consortium of hardware companies
a project to write a new operating system using the principles outlined
in the section on Projects. We expect that a consortium wil be able to
entirely fund the work along with the required hardware.
Third, Richard Gabriel is on the initial taskforce to study the feasibility
of CPL (Common Programming Language) for DARPA. We anticipate that
funding to design and implement a first version of the language will
be obtained. We also hope that this project and the operating system project
will be meshed.
Fourth, the Center will accept some number of contracts from companies
to solve particular problems with a research component involving
programming languages, operating systems, user interfaces, and parallelism.
Hardware
Some hardware is associated with the Qlisp project - namely, 4
Sun 3/160 workstations. We expect to obtain hardware donations from
several hardware vendors. Our goal to is maintain a level of
one workstation for each researcher.
Projects
The following is a sample of the kinds of projects the Center will
undertake.
Qlisp
This project is at the end of the first half of 3 years of work. It is
a DARPA project and is a subcontract from Stanford to Lucid.
The principals on this project at Lucid will be moving to the Center,
and the project will move to the Center with them.
Qlisp is a dialect of Common Lisp designed to run on parallel computers.
The Qlisp project is to implement Qlisp on an Alliant parallel computer.
In addition, the project's aims are to study parallelism in symbolic
mathematical computation, to learn about debugging in a parallel setting,
and to develop techniques for measuring the effectiveness of a parallel
program.
Object-oriented programming language
This project is to design and implement a protoype for the next generation
symbolic programming language. It will be an object-oriented functional
language. Unlike other such languages, this one will be so designed from
the ground up. It will also serve as the programming language for the
operating system project discussed next.
Some informal work has already started on this project, and it is anticipated
that DARPA, NSF, and the EEC will fund this work.
The interesting features of the object-oriented language will be its use
of multiple single inheritance, multiple views of instances, an extensible
type system, a well-developed meta-object layer, and orthogonal design.
Operating system
Operating systems have almost always been closed systems. This operating system
will be an open operating system. The goals of the operating system project will
be to determine whether it is possible and practical to build an operating
system in which multi-lingual programs can be spliced together to build a
larger program, to build user-interfaces that are easily tailorable by
end-users, and to expose to the programmer as first-class objects
address spaces, schedulers, command parsers, page tables, pages, and
user interfaces.
The operating system will support directly single and multiple address
space parallelism and distributed computing.
The operating system will be written in the object oriented language
mentioned above.
Massively Parallel Computation
This project is to design and implement a programming language
suitable for very large parallel computers and some neural networks.
The project will draw on some theoretical results done by
Harlan Sexton and Gunnar Carlsen.
Personnel
The early personnel for the Center will be taken from Lucid. The
first 8 to 10 people will be the senior researchers and professional
programmers.
The first people will be able to join the center in the April - June
time period. It is expected that the Center will be created and
announced by the middle of calendar 1988. Dr. Richard Gabriel will
be the director of the Center, and Prof. John McCarthy will also
join the Center.
∂12-Jan-88 1222 RPG Counter-reaction
The thing I sent you was the thoughts I had about what the center would
do and approximately how it would be organized. I thought it was pretty clear
that the entire Qlisp project would move into the center. Your role is
not spelled out because you never told me what you wanted aside from
you'd like to be affiliated with it and would act as PI until I could.
I'm not entirely sure what needs to be thought out more than what I have.
I can give you names of people and on what projects they would work. I can
include designs of the various parts. I can even given an organization
chart.
I cannot know that this or that funding agency or possibility would
definitely fund one thing or another because I cannot now go out and
claim to be starting such a center without lying. I have talked to DARPA
about the possibilties, but they say that they would be interested once
a real proposal was in front of them, but is it kosher for me to write
a proposal on Stanford's behalf without Stanford's approval?
That is, my reaction to your reaction is that it is also vague and ambiguous.
The writing can certainly be fixed, but I thought this was a working document
between you and me.
Also, I believe our meeting is tommorrow at 9:30, not friday.
-rpg-
∂12-Jan-88 1318 VAL
I'd like to look at your tech. report in which the situation calculus was
first introduced (to see if we may wish to include it in the book). Can you
help me locate it?
∂12-Jan-88 1553 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 15:52:44 PST
Date: Tue 12 Jan 88 15:49:38-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12366117026.31.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301 [bring-your-own-lunch style]
January 15: Dr. Natarajan Shankar (Stanford Univ.),
"Checking Proofs with the Boyer-Moore Theorem Prover"
January 22: Prof. Vaughan Pratt (Stanford Univ.),
"An Introduction to Dynamic Logic"
-------
∂12-Jan-88 1619 ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu Lunch
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 12 Jan 88 16:19:44 PST
Received: by lindy.stanford.edu; Tue, 12 Jan 88 16:17:51 PST
From: ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Tue, 12 Jan 88 16:18:38 PST
Date: 12 Jan 88 16:18 PST
To: JMC@sail.stanford.edu
Subject: Lunch
Date: 12 January 1988, 16:16:48 PST
From: Bloom, Elliott ELLIOTT at SLACVM
To: JMC at SAIL.STANFORD
Subject: Lunch
Dear John,
Tried to get you on the weekend, but you had just left home. Do you have
time to get together for lunch this week? Wed or Friday is ok with me.
Happy New Year,
Elliott
∂12-Jan-88 1716 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software Subcommittee
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 17:16:15 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA01562; Tue, 12 Jan 88 16:38:47 PST
Date: Tue, 12 Jan 88 16:38:47 PST
From: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Message-Id: <8801130038.AA01562@nutmeg.Berkeley.EDU>
To: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.arpa,
jmc@sail.stanford.edu, ouster@nutmeg.Berkeley.EDU
Subject: Software Subcommittee
As I remember from the December meeting of the Committee to Study
International Developments in Computer Science and Technology, the
recipients of this message constitute the software subcommittee,
except that I've substituted Marjory for Bill McHenry (I don't have
Bill's mailing address; Marjory, can you forward this to him, wherever
he is?). I'd like us to start getting our subcommittee report organized.
At the committee meeting, we decided that each subcommittee should
address four topics for its field:
1. Basic technology trends
2. Breakthrough possibilities
3. National players
4. Protectability
The overall committee suggested that we consider four separate
sub-categories of software:
1. Systems software
2. Development environments
3. Artificial intelligence
4. Security
My personal feeling on this is that we should only separate the
subfields if they yield different answers to the four topical
issues.
At this point, we have about 6 weeks in which to put together our
report, and I'd like us to have time to iterate through a couple
of drafts, if possible. Therefore, I'd like to get initial input
from each of you within about the next two weeks, so that it reaches
my electronic mailbox by 5:00 P.M. PST on Friday, January 29th.
I'll then assemble it and prepare a first draft, which I'll
recirculate for additions and corrections. What I suggest is that
you send me short position statements on each of the four topics,
giving your opinions plus references to other work in the area. I'd
particularly like to hear about good sources of numbers on part 3
(national players); there must be some statistics available somewhere
on software sales by country. Your positions need not necessarily
be long (although the more supporting evidence you can provide, the
better). I'm happy to flesh out ideas, but the most important thing
right now is to get the ideas. Each of you has a great deal more
experience in this area than I do, so I'm brutally dependent on your
input.
I suggest that each of us send our positions to the entire group,
since we may trigger more ideas in other people that way. I'm also
happy to receive multiple pieces of mail from each of you; don't
feel obligated to save everything up until the end.
∂12-Jan-88 1935 JUSTESON@Sushi.Stanford.EDU letter of reference
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 19:35:42 PST
Date: Tue 12 Jan 88 17:31:17-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: letter of reference
To: jmc@Sail.Stanford.EDU
Message-ID: <12366135529.17.JUSTESON@Sushi.Stanford.EDU>
Hi, John. I'm starting to apply for teaching jobs in CS.
I wanted to check with you on whether I should give your name as
a reference; I think they normally want letters from advisors, but
then we haven't actually worked together. I'm at the terminals under
the stairs, 2nd floor, and will be till at least 6 tonight, if you
want to discuss it.
John
-------
∂12-Jan-88 2027 Qlisp-mailer new Qlisp constructs
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 88 20:27:34 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02466; Tue, 12 Jan 88 20:29:09 pst
Received: by labrea.Stanford.EDU; Tue, 12 Jan 88 20:27:32 PST
Received: from bhopal.lucid.com by edsel id AA26255g; Tue, 12 Jan 88 16:49:00 PST
Received: by bhopal id AA14070g; Tue, 12 Jan 88 16:51:43 PST
Date: Tue, 12 Jan 88 16:51:43 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801130051.AA14070@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new Qlisp constructs
Here are some new constructs that will be appearing in Qlisp over the next
few months:
1) (QEMPTYP) - a simple predicate that returns T if the run queue is empty
and NIL otherwise. If people want functions to return the number
of processes in the run queue, or the number of processors currently
idle, let me know and I'll see about adding them. QEMPTYP will be
available after our next recompile cycle (i.e. real soon).
2) (QWAIT form) - QWAIT evaluates form and returns its value. If the
evaluation of form causes any new processes to be created, then
QWAIT will wait for them to finish before it returns the value of
form. QWAIT replaces the QCATCH construct proposed in the original
Qlisp paper. QWAIT will probably be available in a month, along
with CATCH/THROW. Note that while QWAIT guarantees that any futures
being computed by processes spawned by the evaluation of form will
have values (i.e. the processes will have finished), the futures
will not be replaced by their values, but, at least initially,
will need to be accessed by:
3) (REALIZE-FUTURE form) - This evaluates form and if its value is a future
then REALIZE-FUTURE will wait, if necessary, for the future to be
realized (i.e. get a value assigned), and then return that value.
This is like TOUCH in Multilisp. If form evaluates to a non-future,
then REALIZE-FUTURE just returns the form's value. REALIZE-FUTURE
won't be available for a few months probably, i.e. until futures get
added. If anyone has a better name for this construct let me know.
(Other possibilities we considered included: GET-FUTURE-VALUE,
CONSUMMATE-FUTURE, DEFUTURIFY, and DELIVER-THE-GOODS.)
Comments on the above to Dick or myself. We'll say more about this at the
Qlisp meeting next Thursday, along with discussing how CATCH/THROW should
work in Qlisp.
Ron
∂13-Jan-88 0054 ME bike locker
∂13-Jan-88 0044 JMC
I'd like to get back my bike locker.
ME - Sure, I'll get you a key Wednesday.
∂13-Jan-88 0139 MATU@Sushi.Stanford.EDU Greeting
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 01:39:38 PST
Date: Wed 13 Jan 88 01:37:56-PST
From: Toshiyuki Matsushim <MATU@Sushi.Stanford.EDU>
Subject: Greeting
To: JMC@Sail.Stanford.EDU
Message-ID: <12366224123.19.MATU@Sushi.Stanford.EDU>
Dear Professor McCarthy:
A Happy New Year and well-comeback to Stanford.
I would like to see you for greeting as I sent a mail at the begining of autumn
quarter, if it would not bother you. I will be very happy, if you inform me when
it is convenient to you.
Thank you.
------------------------
Toshiyuki Matsushima
-------
∂13-Jan-88 0700 JMC
Seitz, Dr. Frederick 212 570-8423, fla. 305 296-8490
∂13-Jan-88 1036 Qlisp-mailer rescheduling meeting
To: qlisp@SAIL.Stanford.EDU
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Since neither Carolyn nor Dick Gabriel can make it tomorrow,
I propose rescheduling qlisp meetings to Wednesday noons
starting next week.
∂13-Jan-88 1234 Qlisp-mailer Halstead papers
To: Qlisp@SAIL.Stanford.EDU
From: Joe Weening <JSW@SAIL.Stanford.EDU>
Copies of the following papers by Bert Halstead are in my office:
An Assessment of Multilisp: Lessons from Experience
MASA: A Multithreaded Processor Architecture for Parallel
Symbolic Computing (with Tetsuya Fujita of NEC)
I'll also bring them to the next Qlisp meeting.
∂13-Jan-88 1355 JUSTESON@Sushi.Stanford.EDU most imminent letter addresses, all for generic positions
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 13:55:07 PST
Date: Wed 13 Jan 88 13:53:30-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: most imminent letter addresses, all for generic positions
To: jmc@Sail.Stanford.EDU
Message-ID: <12366358028.39.JUSTESON@Sushi.Stanford.EDU>
Coming up soonest for requested letters are the following schools that
want letters with the application:
Philip Straffin, Chair
Department of Mathematics and Computer Science
Beloit College
Beloit WI 53511
Prof.~Colin Godfrey
Department of Mathematics and Computer Science
University of Massachusetts at Boston
Boston MA 02125-3393
Dr.~Thomas L.~Pirnot
Department of Mathematics and Computer Science
Kutztown University
Kutztown PA 19530
I'll get you a complete list of schools and dates later this week, complete
as of now, at least.
Thank you for writing for me. Let me know if you want to get together to
talk about it. I'll drop a copy of my generic cover letter in your office
or mail box.
John
-------
∂13-Jan-88 2225 rivin@Gang-of-Four.Stanford.EDU biting the bullet
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 22:25:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06419; Wed, 13 Jan 88 22:26:28 pst
Date: Wed, 13 Jan 88 22:26:28 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801140626.AA06419@Gang-of-Four.Stanford.EDU>
To: jmc@sail, rpg@sail
Subject: biting the bullet
Here is a draft of the "bulletized summary". How does it look?
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
o Lucid Common Lisp has been implemented
o QLET T has been implemented
o QLAMBDA T has been implemented
o Dynamic variables have been implemented using the deep binding
strategy
o Several task-scheduling algorithms have been implemented and tested
o A robust simulator for QLISP has been implemented in Common Lisp.
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance.
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented
The Next Eighteen Months
oo QLISP implementation on the Alliant FX/8
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
o Non-local exits via CATCH and THROW will be implemented
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed.
o Better performance-monitoring tools will be designed.
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
o A more usable program development environment will be designed.
oo Applications Development
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place
o Other application domains in symbolic processing will be investigated
oo Miscelaneous
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having QLISP
available on other machines will make it more widely available to
experimentation by DARPA research community
o An implementation under MACH is being considered as leading to
greater portability of QLISP
∂14-Jan-88 0840 PETTY@RED.RUTGERS.EDU jan-88-techreport-mailing
Received: from RED.RUTGERS.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 08:40:21 PST
Date: 14 Jan 88 11:28:03 EST
From: PETTY@RED.RUTGERS.EDU
Subject: jan-88-techreport-mailing
To: arpanet.mail: ;
cc: petty@RED.RUTGERS.EDU
Message-ID: <12366560924.28.PETTY@RED.RUTGERS.EDU>
Below is a list of our newest technical reports.
The abstracts for these are available for access via FTP with user account
<anonymous> with any password. The file name is:
<library>tecrpts-online.doc
If you wish to order copies of any of these reports please send mail via the
ARPANET to PETTY@RUTGERS. Thank you!!
( ) LCSR-TR-76 - (REVISED) -"A NEW CLASS OF HEURISTIC ALGORITHMS
FOR WEIGHTED PERFECT MATCHING," M.D. Grigoriadis
and B Kalantari.
( ) LCSR-TR-80 - (REVISED) - "KARMARKAR'S ALGORITHM WITH IMPROVED
STEPS", B. Kalantari.
( ) LCSR-TR-91 - "SOLVING LINEAR PROGRAMS IN TH4E STANDARD
FORM BY BISECTION AND A PROJECTIVE FEASIBILITY
ALGORITHM", B. Kalantari.
( ) LCSR-TR-97 - "COMPUTATIONAL GEOMETRY IN A CURVED WORLD,"
D.P. Dobkin and D.L. Souvaine.
( ) DCS-TR-218 - "MANY HARD EXAMPLES FOR RESOLUTION," V. Chvatal
and E. Szemeredi.
( ) ML-TR-8 - "LEARNING APPROXIMATE PLANS IN GAMES," P. Tadepalli.
( ) ML-TR-16 - "APPROXIMATING INTRACTABLE THEORIES: A PROBLEM
SPACE MODEL," J. Mostow, T. Fawcett and N. Bhatnagar.
( ) ML-TR-20 - "ADAPT: AN ANALOGICALLY DIRECTED AUTOMATIC
PROGRAMMING TOOL," W. Cohen and P.B. Franklin.
@end(description)
-------
∂14-Jan-88 0850 PHY
To: "@THEORY.DIS[1,PHY]"@SAIL.Stanford.EDU
Bob Floyd pointed out that Monday, January 18 is a university holiday
in observance of Martin Luther King's birthday.
So Don would like the senior members of the Theory Group of Computer
Science to meet for lunch at the Faculty Club on Monday, January 25
at 11:45 [he teaches at 1:15].
Please let me know ASAP so that I can make the reservations.
- Phyllis
∂14-Jan-88 1110 VAL Commonsense and nonmonotonic reasoning seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
Because of a schedule conflict, we'll have to find another day for the
nonmonotonic seminar this quarter. The possibilities are:
Wednesday, 3:15 or later,
Friday afternoon, any time.
If you have any conflicts or preferences, please send me a message.
Vladimir
∂14-Jan-88 1155 LYN@Sierra.Stanford.EDU re: "College Woman" article on AIDS
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 11:55:39 PST
Date: Thu 14 Jan 88 11:55:32-PST
From: Lyn Bowman <LYN@Sierra.Stanford.EDU>
Subject: re: "College Woman" article on AIDS
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 14 Jan 88 11:28:00-PST
Message-ID: <12366598696.32.LYN@Sierra.Stanford.EDU>
That was in the article.
-------
∂14-Jan-88 1204 LYN@Sierra.Stanford.EDU re: "College Woman" article on AIDS
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 12:04:32 PST
Date: Thu 14 Jan 88 12:04:04-PST
From: Lyn Bowman <LYN@Sierra.Stanford.EDU>
Subject: re: "College Woman" article on AIDS
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 14 Jan 88 11:28:00-PST
Message-ID: <12366600249.37.LYN@Sierra.Stanford.EDU>
Hi again,
Not only was the absence of the story from American newspapers and
newspapers in the article, the first portion of the article included
interviews of American newspaper and newsmagazine editors about
why they had not run the story.
-------
∂14-Jan-88 1258 SHOHAM@Score.Stanford.EDU mtg
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 12:58:24 PST
Date: Thu 14 Jan 88 12:57:04-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: mtg
To: jmc@Sail.Stanford.EDU
Message-ID: <12366609899.13.SHOHAM@Score.Stanford.EDU>
I've stopped by your office sporadically, but I always seem to miss you.
At first I had nothing particular in mind, other than to discuss
research that's on my mind and hear what's on yours. Now I have two
specific things to raise. When's a good time to catch you?
Yoav
-------
∂14-Jan-88 1314 BJORK@Score.Stanford.EDU Re: modem or multiplexer not working
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 13:14:01 PST
Date: Thu 14 Jan 88 13:12:40-PST
From: Steven Bjork <BJORK@Score.Stanford.EDU>
Subject: Re: modem or multiplexer not working
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 14 Jan 88 12:11:00-PST
Message-ID: <12366612737.17.BJORK@Score.Stanford.EDU>
The modem should have the leftmost button depressed, and all others
out. The mux should then resync itself after a short period (.lt. 5min).
I pressed the reset button in the mux at this end. If you pull down the
clear plastic front panel on the mux (it tends to be stiff), there is a
row of dip switches to the left. Just to the
right of them is a small black button with a silver base. Pressing
this button causes a mux reset. The muxes normally maintain sync by
swapping bits every so often. This is seen as a flash on the rx and tx
led's on the mux. If Timothy has banged on the mux dip switches, then
I'll have to talk you through a check.
In any case, I will be on campus for a photography club class tonight,
so I can call you around 7 pm to do any necessary debugging.
--Steve
-------
∂14-Jan-88 1359 MPS Room Change
CS-101 will meet in Bldg. 420, Room 48 starting
with class next Tues, 1-19-87
Pat
∂14-Jan-88 1502 SHOHAM@Score.Stanford.EDU re: mtg
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 15:02:23 PST
Date: Thu 14 Jan 88 15:00:31-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: re: mtg
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 14 Jan 88 14:38:00-PST
Message-ID: <12366632370.47.SHOHAM@Score.Stanford.EDU>
Lunch tomorrow is fine for me. Yoav
-------
∂14-Jan-88 1534 LES Qlisp project continuation
[Draft message to Steve Squires.]
This is an inquiry about the funding level for continuation of the
Qlisp project.
As you know, we need additional funds to continue the development.
Our original proposal laid out a three year program with Lucid as
subcontractor. You decided that you could support only 18 months
at the outset, so we sliced the budget at the 18 month point with the
hope that we could obtain follow-on funding.
Both we and Lucid had trouble finding qualified people initially, which
led to some underexpenditure. The current contract is about to lapse, but
we have requested a no-cost extension and hope to continue on that basis
for a short period.
Our initial proposal budgeted $438.75k for Lucid for the second 18 month
period. With the first period behind us, Lucid now estimates that it
will cost $1,229.5k for them to reach the specified objectives. The question
I have is: is it plausible to boost our original estimate by the $790k
difference.? This would bring the total project budget for the second
18 months to about $2,050k.
∂14-Jan-88 1551 LES re: Qlisp project continuation
[In reply to message rcvd 14-Jan-88 15:48-PT.]
All of the underexpenditure is needed to keep the project going until
the next funding gets here.
∂14-Jan-88 1626 LES re: Qlisp project continuation
[In reply to message rcvd 14-Jan-88 15:57-PT.]
The original 18 months nominally ends tomorrow (though the beginning was
actually kept secret from us for a number of weeks). There is no way
that the continuation can begin at the 18 month point. It IS important
that it begin by the time the residual funds run out.
con-Jan-88 2258 rivin@Gang-of-Four.Stanford.EDU bullets
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 22:58:45 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01667; Thu, 14 Jan 88 23:00:08 pst
Date: Thu, 14 Jan 88 23:00:08 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801150700.AA01667@Gang-of-Four.Stanford.EDU>
To: les@sail
Subject: bullets
Cc: jmc@sail, rpg@sail, edsel!arg@labrea
The below is the (second) draft of the "bulletized" email to Squires,
amended according to Lucid's (in the form of Ron) and JMC's comments.
Do you think it's OK?
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
This has been proceeding at a good pace, after some intial delay
setting up the Stanford-Lucid computer link.
o Lucid Common Lisp has been implemented (March 87)
o QLET T has been implemented (July 87)
o QLAMBDA T has been implemented (December 87)
o Several convenient locking primitives have been designed and
implemented (December 87)
o Dynamic variables have been implemented using the deep binding
strategy (January 88)
o Several task-scheduling algorithms have been implemented and tested
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
QLISP programs have been showing speedups of close to 4x on the
four processors we have. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort (August 87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented (December 1987)
The Next Eighteen Months (the dates below are targets for completion)
oo QLISP implementation on the Alliant FX/8
It is anticipated that QLISP implementation effort will continue
apace, and will coexist with maintenance of the system.
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
(June 88)
o Non-local exits via CATCH and THROW will be implemented (June 88)
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed. (September 88)
o Better performance-monitoring tools will be designed. (September 88)
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
(January 89)
o A more usable program development environment will be designed.
(prototype system by March 89)
oo Applications Development
Experiments will be conducted with implementing medium-to-large
systems.
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place (Continuos through
the next eighteen months)
o Other application domains in symbolic processing will be investigated
(continuos)
oo Miscellaneous
The Alliant FX/8 is limited both in computing power (at most
eight processors) and in generality of code written for it (the
code is likely to not be easy to port to other multiprocessors).
These problems will be addressed.
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having QLISP
available on other machines will make it more widely available to
experimentation by DARPA research community (perhaps get another
machine by August 88)
o An implementation under MACH is being considered as leading to
greater portability of QLISP
∂15-Jan-88 0714 squires@vax.darpa.mil ISO Meeting
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 15 Jan 88 07:13:59 PST
Received: from sun47.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA01786; Fri, 15 Jan 88 10:14:32 EST
Posted-Date: Fri 15 Jan 88 09:57:06-EST
Received: by sun47.darpa.mil (5.54/5.51)
id AA01289; Fri, 15 Jan 88 09:57:07 EST
Date: Fri 15 Jan 88 09:57:06-EST
From: Stephen L. Squires <SQUIRES@vax.darpa.mil>
Subject: ISO Meeting
To: jmc@sail.stanford.edu
Cc: Squires@vax.darpa.mil, Scherlis@vax.darpa.mil
Message-Id: <569257026.0.SQUIRES@VAX.DARPA.MIL>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
I received your 11 Jan 88 letter on sending Clinger and Gabriel to the
Paris meeting of ISO on Common Lisp.
I agree that it is appropriate for the QLisp project to pay for this travel.
-------
∂15-Jan-88 0800 JMC
seitz juilland about Bork
∂15-Jan-88 1114 kathy@ratliff.cs.utexas.edu UT reimbursement for moving expenses
Received: from sally.utexas.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 11:14:49 PST
Received: by sally.utexas.edu (5.54/5.51)
id AA10599; Fri, 15 Jan 88 13:14:55 CST
Date: Fri, 15 Jan 88 13:14:47 CST
From: kathy@ratliff.cs.utexas.edu (Kathy Guajardo)
Posted-Date: Fri, 15 Jan 88 13:14:47 CST
Message-Id: <8801151914.AA16617@ratliff.cs.utexas.edu>
Received: by ratliff.cs.utexas.edu (5.54/5.51)
id AA16617; Fri, 15 Jan 88 13:14:47 CST
To: jmc@sail.stanford.edu
Subject: UT reimbursement for moving expenses
Cc: kathy@ratliff.cs.utexas.edu
Prof. McCarthy,
The voucher reimbursing you for moving expenses back to Stanford
requires your signature. (Total $2,129.00)
Elizabeth Manning asked me to contact you and suggest that if
you would like to expedite the reimbursement, you could authorize
Dr. Dale or Elizabeth to sign it on your behalf. I will mail
it to you if you prefer to sign it.
Please advise.
Kathy Guajardo
Computer Sciences Dept.
University of Texas at Austin
∂15-Jan-88 1445 edsel!arg@labrea.Stanford.EDU bullets - part II
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:44:47 PST
Received: by labrea.Stanford.EDU; Fri, 15 Jan 88 14:44:50 PST
Received: from bhopal.lucid.com by edsel id AA10568g; Fri, 15 Jan 88 14:12:32 PST
Received: by bhopal id AA01020g; Fri, 15 Jan 88 14:15:30 PST
Date: Fri, 15 Jan 88 14:15:30 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801152215.AA01020@bhopal.lucid.com>
To: rivin@gang-of-four.stanford.edu
Cc: jmc@sail.Stanford.EDU, rpg@sail.Stanford.EDU, les@sail.Stanford.EDU
In-Reply-To: Igor Rivin's message of Thu, 14 Jan 88 23:00:08 pst <8801150700.AA01667@Gang-of-Four.Stanford.EDU>
Subject: bullets - part II
Igor - A couple of comments on your revised bullets:
Under applications development, what programs have achieved speedups
"close to 4x"? All the ones I know of ranged from 2-3 at best. Also
I'ld really like to know about what "ideas have been formed about the
development tools required for facilitating Qlisp programming". Are
you guys holding out on folks us here at Lucid?
Under the next 18 months implementation schedule, you should move up
the date for CATCH & THROW --- I expect that they'll be implemented
by March 88. Also I guess I should point out that the last four
points --- resource management, monitoring tools, benchmarks, and
development environment --- are all predicated on an increase in funds
to pay for their development. They are all extensions to the work
proposed in the original contract and Lucid can't do them based on
the original contract budget, so I wouldn't promise them to DARPA
unless we're asking for more money than what's in the original Qlisp
proposal budget, or unless the amount of funds allocated to Lucid is
increased some other way. Otherwise they look fine.
Note the conventional spelling of "continuous".
Ron
∂15-Jan-88 1747 pehoushe@Gang-of-Four.Stanford.EDU other primitive parallel forms?
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 17:47:43 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03155; Fri, 15 Jan 88 15:34:06 pst
Date: Fri, 15 Jan 88 15:34:06 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8801152334.AA03155@Gang-of-Four.Stanford.EDU>
To: JMC@sail
Cc: JDP@sail, JSW@sail
Subject: other primitive parallel forms?
Has anyone proposed something like PCALL in MultiLisp for Qlisp?
Pcall basically evaluates the arguments of a function call in
parallel. I can imagine writing code that looks like the following:
(defun tak (x y z)
(if (not (< y x))
z
#!(tak (tak (1- x) y z)
(tak (1- y) z x)
(tak (1- z) x y))))
Using this hack, very functional programs require very little change.
(defun fib (n)
(if (< n 2)
n
#!(+ (fib (- n 2)) (fib (1- n)))))
Where the #! means that evaluating the arguments of the following function
invocation in parallel is permissible, but not mandatory.
This form of parallelism seems alot more "functional" than Qlet. The
#! expands into something that tests QEMPTYP to see whether it should
spawn processes. The decrease in overhead due to binding variables leads
to good preformance of FIB, TAK, and TOUCH. -dan
∂15-Jan-88 1809 nilsson@Tenaya.stanford.edu schwartz
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 18:08:58 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA14242; Fri, 15 Jan 88 18:08:49 PST
Date: Fri, 15 Jan 88 18:08:49 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801160208.AA14242@Tenaya.stanford.edu>
To: GENESERETH@Score.stanford.edu
Cc: sjg@Sail.stanford.edu, jmc@Sail.stanford.edu, tob@Sail.stanford.edu,
latombe@Score.stanford.edu
In-Reply-To: Mike Genesereth's message of Fri 15 Jan 88 17:07:03-PST <12366917551.22.GENESERETH@Score.Stanford.EDU>
Subject: schwartz
I can't make it on Tuesday, but I could make a strategy meeting anytime
Wednesday morning. (Let's invite Yoav also.) -Nils
∂15-Jan-88 1823 latombe@coyote.stanford.edu Re: schwartz
Received: from coyote.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 18:23:10 PST
Received: by coyote.stanford.edu; Fri, 15 Jan 88 18:23:42 PST
Date: Fri, 15 Jan 88 18:23:42 PST
From: Jean-Claude Latombe <latombe@coyote.stanford.edu>
Subject: Re: schwartz
To: GENESERETH@score.stanford.edu, jmc@sail.stanford.edu,
latombe@score.stanford.edu, nilsson@score.stanford.edu,
sjg@sail.stanford.edu, tob@sail.stanford.edu
Tuesday 2:30 is fine with me. JC.
∂15-Jan-88 1927 SHOHAM@Score.Stanford.EDU letter from JMC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 19:27:10 PST
Date: Fri 15 Jan 88 16:13:01-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: letter from JMC
To: bscott@Score.Stanford.EDU
cc: jmc@Score.Stanford.EDU
Message-ID: <12366907715.44.SHOHAM@Score.Stanford.EDU>
Betty,
JMC has been instantaneous in generating a support letter. Here it
is. I guess the thing to do is type up a real letter, have the lawyer
approve it, and then get it signed and included in the package.
Yoav
This letter is in support of making an exception to the rule about
Fullbright scholars returning to their countries of origin in the case of
Professor Yoav Shoham in connection with his work as Assistant Professor
of Computer Science at Stanford University.
There is a great shortage of qualified people working
in Shoham's area which happens to be my specialty also.
The field of using mathematical logic to express common sense
knowledge in a way that can be used by intelligent computer
programs started about 30 years ago, but progress has been slow.
The main reason has been the shortage of people who combine the
necessary knowledge and ability in logic with the necessary
interest in the basically non-mathematical problem of
common sense reasoning and problem solving.
This specialty is important to maintaining the U.S. lead in
technology related to defense. The current DARPA research projects
in developing artificial intelligence systems for a pilots associate,
an autonomous land vehicle and naval battle management will all experience
performance limitations related to their ability to use common
sense knowledge.
Shoham is one of the few people who combine the abilities required
to advance this field as evidenced by his PhD thesis and his more recent
work. This is why we chose him for our faculty and why he is included in our
current DARPA project on developing the logic approach to artificial
intelligence. We expect him to develop this difficult field by his own
research and also to help students get started in it.
Sincerely,
-------
∂15-Jan-88 1928 GENESERETH@Score.Stanford.EDU schwartz
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 19:28:01 PST
Date: Fri 15 Jan 88 17:07:03-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: schwartz
To: nilsson@Score.Stanford.EDU, sjg@Sail.Stanford.EDU, jmc@Sail.Stanford.EDU,
tob@Sail.Stanford.EDU, latombe@Score.Stanford.EDU
Message-ID: <12366917551.22.GENESERETH@Score.Stanford.EDU>
Gentlemen,
I was thinking that it might be a good idea for us to get together
sometime soon to plot strategy for Schwratz's visit. Nils agrees with
this. As a first crack at a meeting time let me suggest 2:30 next Tuesday.
Can all of you who are interested make it then?
mrg
-------
∂15-Jan-88 2000 JMC
check stubs re acm but also xerox for file
∂15-Jan-88 2026 RPG New Tasks
To: rivin@GANG-OF-FOUR.STANFORD.EDU
CC: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
LES@SAIL.Stanford.EDU, edsel!arg@LABREA.STANFORD.EDU
We should mention:
evaluate porting to Encore under Mach
evaluate distributed extensions under Mach
evaluate multi-tasking under Mach so that
parallel programs can be run on uniprocessors under
Mach's facilities.
I discussed these with Scherlis this morning.
-rpg-
∂16-Jan-88 0947 latombe@coyote.stanford.edu Re: schwartz
Received: from coyote.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Jan 88 09:47:50 PST
Received: by coyote.stanford.edu; Sat, 16 Jan 88 09:48:20 PST
Date: Sat, 16 Jan 88 09:48:20 PST
From: Jean-Claude Latombe <latombe@coyote.stanford.edu>
Subject: Re: schwartz
To: GENESERETH@score.stanford.edu, nilsson@tenaya.stanford.edu
Cc: jmc@sail.stanford.edu, latombe@score.stanford.edu, sjg@sail.stanford.edu,
tob@sail.stanford.edu
Wednesday morning is also fine with me if it is early enough (before 10). JC.
∂16-Jan-88 1329 binford@anaconda.Stanford.EDU schwartz
Received: from anaconda.Stanford.EDU.stanfo (Anaconda.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 16 Jan 88 13:28:57 PST
Received: by anaconda.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA04290; Sat, 16 Jan 88 13:33:49 PST
Date: Sat, 16 Jan 88 13:33:49 PST
From: binford@anaconda.stanford.edu (Tom Binford)
Message-Id: <8801162133.AA04290@anaconda.Stanford.EDU.stanford.edu>
To: GENESERETH@score.stanford.edu
Cc: nilsson@score.stanford.edu, sjg@sail.stanford.edu, jmc@sail.stanford.edu,
tob@sail.stanford.edu, latombe@score.stanford.edu
Subject: schwartz
I will be away Tues and Wed of next week. I return Thursday.
∂16-Jan-88 2246 Mailer re: nonviolence
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 88 22:46:18 PST
Date: Sat, 16 Jan 88 22:45:45 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: re: nonviolence
To: JMC@SAIL.Stanford.EDU
cc: su-etc@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri, 15 Jan 88 22:41:00 PST
Message-ID: <12367241354.16.CHIN@SUMEX-AIM.Stanford.EDU>
John:
What I meant by the "failure of the parliamentary system" is
largely the inability of congress to curb some of the illegal and
undemocratic excesses of the administration. For example, I think
that most of our elected officials would have been against the
administration's Contra policy if they had realized the true extent
and illegality of their actions--as the contragate hearings have
pointed out.
Another interesting point is to compare the past results of violent
vs. non-violent protest. Most non-violent protestors are now reverred,
and the morality of the positions that they took have been borne out
in time (e.g. Martin Luther King, Ghandi); whereas I cannot think of
violent protestors who are held in as high esteem. To lump non-violent
and violent protest together in the cavalier way that Boman does is
erroneous and misleading.
-------
∂17-Jan-88 1257 Mailer re: nonviolence
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 12:56:54 PST
Date: Sun 17 Jan 88 12:52:47-PST
From: Joseph I. Pallas <PALLAS@Sushi.Stanford.EDU>
Subject: re: nonviolence
To: su-etc@Sail.Stanford.EDU
cc: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sat 16 Jan 88 23:35:00-PST
Message-ID: <12367395549.10.PALLAS@Sushi.Stanford.EDU>
I'm sick and tired of hearing this lie from JMC and other apologists
for the executive's usurpation of power:
Congress cannot tell the President what to do in foreign policy except
by restrictions on the use of appropriated money.
Without the advice and consent of the Senate, the President can
neither "make treaties" nor "appoint ambassadors." The Congress has the
power "to regulate commerce with foreign nations, ... to regulate the value
of foreign coin, ... to define and punish offences against the law of
nations, ... [and] to declare war."
The Constitution enumerates exactly two things the President can do
which relate to foreign policy, and both require consent from the
Senate. It neither states nor implies that the President has any
other function with respect to foreign policy. It does enumerate the
President's powers, including to be Commander-in-Chief of the Army and
Navy (the Marines, for those who don't know, are part of the Navy; the
Air Force is not mentioned and may be illegal), to grant reprieves and
pardons, to make treaties and appoint ambassadors with the consent of
the Senate, to make recommendations to the Congress, to receive
ambassadors, to commission officers of the U.S., and to "take care
that the laws be faithfully executed."
Now, what the hell is foreign policy other than making treaties,
declaring war, sending ambassadors, levying duties, and distributing
funds from the proverbial purse whose strings are held by the
Congress?
Let me also disagree with JMC on a matter of opinion: there was
nothing at all particularly surprising about the administration's
actions; they acted just the way one would expect a bunch of thugs to
act. And they weren't dealing with Iran in an attempt to aid the
Contras, they were attempting to aid the Contras while dealing with
Iran.
joe
-------
∂17-Jan-88 1359 cphoenix@portia.Stanford.EDU re: destroying the credibility of famous people
Received: from jessica.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 13:59:08 PST
Received: from Portia.Stanford.EDU by jessica.Stanford.EDU with TCP; Sun, 17 Jan 88 13:58:24 PST
Received: by Portia.STANFORD.EDU (1.2/Ultrix2.0-B)
id AA26089; Sun, 17 Jan 88 14:00:28 pst
Date: Sun, 17 Jan 88 14:00:28 pst
From: cphoenix@portia.Stanford.EDU (Chris Phoenix)
Message-Id: <8801172200.AA26089@Portia.STANFORD.EDU>
To: JMC@sail.stanford.edu
Subject: re: destroying the credibility of famous people
Has he been attacked by the same people as are attacking MLK?
∂17-Jan-88 1413 paulf@umunhum.stanford.edu re: MLK Day
Received: from umunhum.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Jan 88 14:13:43 PST
Received: by umunhum.stanford.edu; Sun, 17 Jan 88 14:11:22 PST
Date: Sun, 17 Jan 88 14:11:22 PST
From: Paul Flaherty <paulf@umunhum.stanford.edu>
Subject: re: MLK Day
To: JMC@sail.stanford.edu
Ack. I hope that was a typo.
-=paulf
∂17-Jan-88 1420 cphoenix@portia.Stanford.EDU re: destroying the credibility of famous people
Received: from jessica.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 14:20:45 PST
Received: from Portia.Stanford.EDU by jessica.Stanford.EDU with TCP; Sun, 17 Jan 88 14:20:01 PST
Received: by Portia.STANFORD.EDU (1.2/Ultrix2.0-B)
id AA26761; Sun, 17 Jan 88 14:22:03 pst
Date: Sun, 17 Jan 88 14:22:03 pst
From: cphoenix@portia.Stanford.EDU (Chris Phoenix)
Message-Id: <8801172222.AA26761@Portia.STANFORD.EDU>
To: JMC@sail.stanford.edu
Subject: re: destroying the credibility of famous people
That was my point, that these people who try to destroy MLK and Ghandi seem
to selectively ignore the problems of other famous people.
Sorry if it wasn't clear.
∂17-Jan-88 1448 Mailer Re: peace talks
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 14:48:06 PST
Date: Sun, 17 Jan 88 14:47:28 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: Re: peace talks
To: JMC@SAIL.Stanford.EDU
cc: su-etc@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun, 17 Jan 88 00:17:00 PST
Message-ID: <12367416427.18.CHIN@SUMEX-AIM.Stanford.EDU>
Most of the so-called "political prisoners" in Nicaragua are
ex-Somoza national guards, and have been convicted of crimes such as
torture, death squad activity, etc. Daniel Ortega has agreed to
release them if the U.S. will be willing to take them...
What will happen if the peace process does move forward and the
Contras lose there U.S. backing and are forced to leave Honduras?
They will have no place to go except Miami. It should be interesting
to see how 6,000 mercenaries that have been taught to assasinate
judges, mayors, and school teachers, bomb health clinics, and mine
harbors, along with several thousand ex-Somocista national guardsmen
improve the crime ridden, violent environment in Miami...
Another news bulletin: Nobel Prize winner and Costa Rican president
Oscar Arias has told the Contras to "get out" of Costa Rica.
-------
∂17-Jan-88 1510 nilsson@Tenaya.stanford.edu cs 520
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Jan 88 15:10:38 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15425; Sun, 17 Jan 88 15:08:57 PST
Date: Sun, 17 Jan 88 15:08:57 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801172308.AA15425@Tenaya.stanford.edu>
To: nilsson@tenaya.stanford.edu, jmc@sail.stanford.edu,
feigenbaum@sumex-aim.stanford.edu, winograd@csli.stanford.edu,
zm@sail.stanford.edu, shortliffe@sumex-aim.stanford.edu,
buchanan@sumex-aim.stanford.edu, genesereth@score.stanford.edu,
latombe@coyote, binford@coyote.stanford.edu, tenenbaum@spar-20.arpa,
clancey@sumex-aim.stanford.edu, shoham@score.stanford.edu,
weise@mojave.stanford.edu, reges@score.stanford.edu,
snow@sushi.stanford.edu, tajnai@score
Subject: cs 520
Attached is the announcement I plan to use for CS520 this year. Although
my schedule is fuller than I can really handle well, I will take
responsibility for cs520 again this year as planned. However, I would
like someone to volunteer to do it next year (1989).
I'll give our faculty first crack at volunteering to give an
"applications-oriented" talk in cs520. Please respond, if you'd like,
by sending me a title and two or three dates that are possible for
you. (Spring Quarter Tuesdays, 11:00-11:50).
I wouldn't nind someone volunteering to give a talk entitled something
like "Overview of AI applications" which would stress any themes or
principles that are important in AI applications work.
I'd also like suggestions about "musts" that I must invite to give
a talk in this series. If any of you know of out-of-Bay-area people
who are coming in the spring and could be persuaded to talk, please
advise.
My must list so far would include: Tenenbaum/Cutkowski (first-cut),
Hart/Duda/Risch (Syntel and Lending/Underwriting advisors),
Levitt/Hayes-Roth (expert systems for building layout), Byron Davies
(Fable), Hobbs (Candide---natural language system), someone to
talk about PRS applications to space-station monitoring, ...
------
SEMINAR ANNOUNCEMENT
CS 520 ARTIFICIAL INTELLIGENCE RESEARCH SEMINAR
APPLICATIONS OF ARTIFICIAL INTELLIGENCE
Tuesdays 11:00 a.m. (Televised over SITN)
Spring Quarter 1988
Convener: Nils Nilsson
This year, CS520 will concentrate on applications of AI. Stanford and
the Stanford area have produced many of the world's most exciting and
innovative AI applications. We will be hearing about these from the
very people who have developed them. Each seminar will be
self-contained and will be accessible to those who have already
completed one of the AI courses at Stanford (or equivalent).
First meeting, Tuesday, March 29
Last meeting, Tuesday, May 31
∂17-Jan-88 1721 VAVASIS@Sushi.Stanford.EDU MLK day
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 17:21:28 PST
Date: Sun 17 Jan 88 17:17:22-PST
From: Stephen Vavasis <VAVASIS@Sushi.Stanford.EDU>
Subject: MLK day
To: jmc@Sail.Stanford.EDU
Message-ID: <12367443716.21.VAVASIS@Sushi.Stanford.EDU>
Thanks for your message posted to SU-ETC about MLK day. You
are right in pointing out I did not provide any evidence that
the charges made by Hoover against MLK were false.
You accuse me of reading between the lines too much when I said
that a person who criticizes MLK's work without explicitly supporting
civil rights for blacks will be labeled a racist. Perhaps
liberals are too eager to read between the lines. On the other
hand, you are guilty of the same thing in your message, because
you lumped me in with ``liberals'' in your message, even though
I never said I was a liberal! Presumably, you decided that what
I had said would be an appropriate thing for a liberal to say
(I don't deny that!) so you lumped me in with them.
-- Steve Vavasis
-------
∂17-Jan-88 1819 rivin@Gang-of-Four.Stanford.EDU bullets - part II
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 18:19:41 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06688; Sun, 17 Jan 88 18:20:54 pst
Date: Sun, 17 Jan 88 18:20:54 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801180220.AA06688@Gang-of-Four.Stanford.EDU>
To: edsel!arg@labrea.Stanford.EDU
Cc: jmc@sail.Stanford.EDU, rpg@sail.Stanford.EDU, les@sail.Stanford.EDU
In-Reply-To: Ron Goldman's message of Fri, 15 Jan 88 14:15:30 PST <8801152215.AA01020@bhopal.lucid.com>
Subject: bullets - part II
The programs achieving close to 4x speedups are some of the sorts, fib
and tak (and perhaps others that slipped my mind) The development
tools considered so far include, for example, having X-windows
support, so that, for example, each processors types out debugging
info, etc, to a separate window. Nothing too deep so far...
I have incorporated your schedule suggestions into the rerevised
proposal
(watch this space for your copy...)
∂17-Jan-88 1825 rivin@Gang-of-Four.Stanford.EDU rere...revised proposal
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 18:25:12 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06699; Sun, 17 Jan 88 18:26:28 pst
Date: Sun, 17 Jan 88 18:26:28 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801180226.AA06699@Gang-of-Four.Stanford.EDU>
To: rpg@sail, jmc@sail, les@sail, edsel!arg@labrea
Subject: rere...revised proposal
I have munged the proposal in accordance to the comments I received.
How is this?
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
This has been proceeding at a good pace, after some intial delay
setting up the Stanford-Lucid computer link
o Lucid Common Lisp has been implemented (March 87)
o QLET T has been implemented (July 87)
o QLAMBDA T has been implemented (December 87)
o Several convenient locking primitives have been designed and
implemented (December 87)
o Dynamic variables have been implemented using the deep binding
strategy (January 88)
o Several task-scheduling algorithms have been implemented and tested
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
QLISP programs have been showing speedups of close to 4x on the
four processors we have. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
In the current Lucid implementation, it takes about 1 millisecond to spawn
a process, so as long as the granularity of a problem is considerably greater
than that, good speedups can reasonably be expected. The number of
active processes should be no more than around a thousand and certainly
no less than the number of processors in order for reasonable speedups to
be achievable. In many of the applications below, these conditions have
been met.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming.
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort (August 87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented (December 1987)
The Next Eighteen Months (the dates below are targets for completion, work
is predicated on the proposed levels of funding)
oo QLISP implementation on the Alliant FX/8
It is anticipated that QLISP implementation effort will continue
apace, and will coexist with maintenance of the system.
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
(June 88)
o Non-local exits via CATCH and THROW will be implemented (March 88)
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed. (September 88)
o Better performance-monitoring tools will be designed. (September 88)
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
(January 89)
o A more usable program development environment will be designed.
(prototype system by March 89)
oo Applications Development
Experiments will be conducted with implementing medium-to-large
systems.
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place (Continuous through
the next eighteen months)
o Other application domains in symbolic processing will be investigated
(continuous)
oo Miscellaneous
The Alliant FX/8 is limited both in computing power (at most
eight processors) and in generality of code written for it (the
code is likely to not be easy to port to other multiprocessors).
These problems will be addressed.
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having QLISP
available on other machines will make it more widely available to
experimentation by DARPA research community (perhaps get another
machine by August 88)
o Porting to Encore under MACH will be evaluated (by August 88)
o Distributed extensions under MACH will be evaluated (by January 89)
o Multitasking will be evaluated under MACH, so that parallel programs
can be run on uniprocessors. (by January 89)
∂17-Jan-88 1922 Mailer re: peace talks
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 19:22:39 PST
Date: Sun, 17 Jan 88 19:22:08 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: re: peace talks
To: JMC@SAIL.Stanford.EDU
cc: su-etc@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun, 17 Jan 88 15:50:00 PST
Message-ID: <12367466428.16.CHIN@SUMEX-AIM.Stanford.EDU>
I suggest that you read any of the following (I can provide you with a
much longer list if you would like):
Brody: Contra Terror in Nicaragua (report of a fact finding mission by
the former Asst. Atty. General of New York)
Barry: The Central America Fact Book.
Berryman: Inside Central America.
Chomsky: Turning the Tide.
Rosset: Nicaraguan Reader.
Over half of the 7,000 captured members of Somoza's National Guard were
released or pardoned by 1981, and those remaining were entitled to
judicial review of their sentences.
On the other hand, JMC, would you please explain why BOTH Amnesty
International and Americas Watch both found that torture, forced
disappearances and extrajudicial killings were "systematically
practiced" in El Salvador and Guatemala, but not Nicaragua?
Also, somehow JMC has failed to notice that over 40,000 civilians have
been killed by security forces or government-allied death squads in
El Salvador since 1979, and 50,000 murdered in Guatemala. The
Sandanistas have never been accused of such massacres.
Another question, JMC: If there is legitimate backing for the Contras
within Nicaragua, why are they still in Honduras after 8 years?
-------
∂17-Jan-88 1945 Mailer re: peace talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 19:45:08 PST
Date: Sun 17 Jan 88 19:40:54-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: re: peace talks
To: CHIN@SUMEX-AIM.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12367466428.16.CHIN@SUMEX-AIM.Stanford.EDU>
Message-ID: <12367469846.22.TEICH@Sushi.Stanford.EDU>
Homer, in the last place I lived, they had a copy of last year's Amnesty
International report. I found it interestingly biased. While it spent a lot
of time complaining about the Contra's, it didn't once mention the communist
rebels in El Salvador. It was especially interesting to see, since those
"freedom fighters" shot up polling places and the people in those places
during the last couple elections.
It also did mention that Nicaragua had an enormous number of prisoners
and very wquickly mentioned that there were rumours of tortures. Meanwhile,
the coverage of the El Salvadorean story was much more detailed.
Having read about both countries I just came to the conclusion that the
story in Nicaragua was almost, though not as bad as El Salvador; but that
it was no where near as important to AI than the El Salvador info.
david
-------
∂18-Jan-88 0902 GOODMAN%uamis@rvax.ccit.arizona.edu How are you all doing??
Received: from rvax.ccit.arizona.edu by SAIL.Stanford.EDU with TCP; 18 Jan 88 09:01:49 PST
Date: Mon, 18 Jan 88 08:23 MST
From: GOODMAN%uamis@rvax.ccit.arizona.edu
Subject: How are you all doing??
To: DUANE.ADAMS@c.cs.cmu.edu, BLUMENTHAL@a.isi.edu, DONGARRA@anl-mcs.arpa,
GANNON%RDVAX.DEC@decwrl.dec.com, JAHIR@athena.mit.edu, HEARN@rand-unix.arpa,
JLH@sierra.stanford.edu, JMC@sail.stanford.edu, MCHENRY@GUVAX.BITNET,
OUSTER@ginger.berkeley.edu, Ralston@mcc.com, CWEISSMAN@dockmaster.arpa
X-VMS-To: @NAS
Not much time left until the first week of March. I'd appreciate status
statements from all of you.
∂18-Jan-88 1117 T.TECHNO@MACBETH.STANFORD.EDU Hello. I don't mean to bother you, but I was one of the students at
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 11:17:24 PST
Date: Mon 18 Jan 88 11:16:54-PST
From: The Technocrat <T.TECHNO@MACBETH.STANFORD.EDU>
Subject: Hello. I don't mean to bother you, but I was one of the students at
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12367640240.310.T.TECHNO@MACBETH.STANFORD.EDU>
the computer science summer camp, and, although I'm now back in Westford, MA,
(I'm a junior in high school), I am soon supposed to write a report on the
history of AI, and was wondering if sometime in the next couple of weeks I
could conduct a brief interview with you over this system.
Would that be alright with you? It'll probably be several weeks....
-------
∂18-Jan-88 1513 @Score.Stanford.EDU:AI.THROOP@R20.UTEXAS.EDU Making Macro Moves
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 15:12:54 PST
Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Mon 18 Jan 88 15:08:44-PST
Date: Mon 18 Jan 88 17:12:23-CST
From: David Throop <AI.THROOP@R20.UTEXAS.EDU>
Subject: Making Macro Moves
To: jmc@SCORE.STANFORD.EDU, rdz@SCORE.STANFORD.EDU
Message-ID: <12367683109.28.AI.THROOP@R20.UTEXAS.EDU>
We discussed that I would continue to work on the code, with the idea of
defining an equivalency class on the set of squares
x x ! !
x x ! !
x x ! !
x x x x
that measured only the number of intervening tiles between the 3 and 4
(traveling clockwise), and then returning a sequence of moves that
reached a lower equivalency class as a macro-move.
The immediate problem with the macro-move idea is that it runs into the
other bugaboo - the problem when two states are both better than each
other. In particular
1 2 3 x
x x x 4 ; Position 1
x x x blank
x x x x
1 2 blank x
x x 4 x ; Position 2
x x 3 x
x x x x
Position 1 is better than Position 2 by the Manhattan-Distance
heuristic, while Position 2 is better than Position 1 under the view of
looking at equivalency classes. Position 2 IS the favored position - it
is the one closest to the position with the entire first row filled in.
With clever coding, I can keep the system from falling into the trap -
but the result is not satisfying - the contradiction between the
heuristics gets lost down in the code.
I imagine the following possible approaches to the standoff:
Having an ordered set of goals and having each goal have a different
set of applicable heuristics. So we could first achieve the goal of
getting the 3 into correct position, then the goal of getting the 4 into
the 6-square area, then repeatedly achieve the goal of reducing the
equivalency class, then achieve the goal of getting both the 3 and the 4
into their standard positions, with a different goal and a different set
of applicable heuristics at each step.
Marking the goal of getting the 3 into standard position as solved
when it is reached, and having the manhattan distance then only look at
the next tile. So after position 2 is reached by undoing position 1,
position 1 will not be better than postion 2 by the manhattan distance
heuristic. This involves keeping a record of how far the chain has been
completed by any position.
David
-------
∂18-Jan-88 1518 bill@isl.Stanford.EDU nuclear tests
Received: from isl.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 15:18:44 PST
Received: by isl.Stanford.EDU (3.2/4.7); Mon, 18 Jan 88 15:18:19 PST
From: bill@isl.Stanford.EDU (Bill Moore)
To: jmc@sail
Subject: nuclear tests
Date: Mon, 18 Jan 88 15:18:17 PST
Thanks for the clarification. KPFA led me to believe
that the tests were not publicized at all. They also
said that some new weapons were being tested. Do you
know anything about this?
Bill
∂18-Jan-88 1630 jcm@navajo.stanford.edu baby gates
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 88 16:29:23 PST
Received: by navajo.stanford.edu; Mon, 18 Jan 88 16:25:20 PST
Date: Mon, 18 Jan 88 16:25:20 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: baby gates
To: jmc@sail.stanford.edu
Just scrolled by your note.
Do you still have them?
John Mitchell
∂18-Jan-88 1837 Qlisp-mailer some agenda items for Wednesday's meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 18:37:05 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01020; Mon, 18 Jan 88 18:37:31 pst
Received: by labrea.Stanford.EDU; Mon, 18 Jan 88 18:37:09 PST
Received: from bhopal.lucid.com by edsel id AA07563g; Mon, 18 Jan 88 18:30:24 PST
Received: by bhopal id AA12353g; Mon, 18 Jan 88 18:33:35 PST
Date: Mon, 18 Jan 88 18:33:35 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801190233.AA12353@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: some agenda items for Wednesday's meeting
Here are four agenda items for the Qlisp meeting Wednesday:
1) What's happening with the DARPA proposal?
Both the contract extension for Lucid & the next 18 month proposal.
2) Description of most current version of Qlisp implementation.
Also what Lucid is currently working on.
3) Some experimental results obtained using Qlisp.
4) Discussion of semantics of CATCH and THROW in Qlisp (time permitting).
Ron
∂18-Jan-88 1852 JSW
∂18-Jan-88 1848 JMC didn't work
<ctrl>q followed by ≥ to emacs resulted in ↑] or maybe it was ↑[
rather than ≥.
JJW - This means Emacs doesn't know your terminal can display all
128 characters. We'll have to see if it can be convinced to send
them to SAIL.
∂18-Jan-88 1912 Mailer re: peace talks
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 19:12:50 PST
Date: Mon, 18 Jan 88 19:12:07 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: re: peace talks
To: TEICH@Sushi.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12367469846.22.TEICH@Sushi.Stanford.EDU>
Message-ID: <12367726751.15.CHIN@SUMEX-AIM.Stanford.EDU>
David:
"they had a copy of last year's Amenstry Internationla report. I
found it interestingly biased."
That is the level that most apologists for the administration
-------
∂18-Jan-88 1948 Qlisp-mailer place of meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 19:48:22 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01186; Mon, 18 Jan 88 19:48:41 pst
Date: Mon, 18 Jan 88 19:48:41 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801190348.AA01186@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: place of meeting
Is mjh301...
∂18-Jan-88 2005 Mailer re: peace talks
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 20:05:37 PST
Date: Mon, 18 Jan 88 20:04:58 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: re: peace talks
To: TEICH@Sushi.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12367469846.22.TEICH@Sushi.Stanford.EDU>
Message-ID: <12367736371.15.CHIN@SUMEX-AIM.Stanford.EDU>
Sorry about my previous incomplete message...
David:
In your last message you write:
> "...in the last place I lived, they had a copy of last year's Amnesty
> International report. I found it interestingly biased...
> ...Having read about both countries I just came to the conclusion
> that the story in Nicaragua was almost, though not as bad as
> El Salvador..."
Amnesty International has long criticized the human rights abuses in
the Soviet Union and other Soviet Bloc countries, and has a reputation
for being politically neutral. Now that its report contradicts
the picture that the administration is trying to paint about what
is REALLY happening in Central America, it is labelled by apologists
for the administration as "biased".
Look at the facts:
1. While the US media have focused on La Prensa, the violent
extermination of two Salvadoran dailies--La Cronica and El
Independiente--in the early 1980s has been virtually ignored. 65
reporters have been murdered by government-allied death squads in El
Salvador and Guatemala in recent years.
2. On October 27, 1987, the president of El Salvador's Human Rights
Commission, Herbert Anaya, was assassinated in broad daylight as he
was taking his two daughters to school. He was the SEVENTH official
of the group to be murdered by government allied death squads, and
the last surviving member of the original Human Rights Commission.
3. Since 1979, over 40,000 civilians have been killed by security
forces or government-allied death squads in El Salvador. Over 50,000
have been murdered in Guatemala.
Please tell me, how has Nicaragua has been "almost as bad" as El Salvador?
-------
∂18-Jan-88 2155 JSW Emacs and WAITS characters
The GNU Emacs code that decides how to display characters has two
options for codes less than 40 octal: either "↑" followed by the
character that is 100 octal higher, or "\" followed by the character's
octal code. I asked Marty what it would take to display the graphic
on a DMWAITS terminal, and he said Emacs will need to use an escape
sequence, since the normal meaning of characters less than 40 is for
terminal functions such as insert/delete and cursor positioning.
It wouldn't be too hard to modify Emacs to do this, but to do it right
would involve making it work on arbitrary terminals which might use
different escape sequences to display the special characters. This
would also mean making our Emacs non-standard, which is my main reason
to hesitate doing it.
∂19-Jan-88 0750 PHY
To: "@THEORY.DIS[1,PHY]"@SAIL.Stanford.EDU
Okay, NEW change of time for the senior members of the Theory group
of Computer Science to meet: Wednesday, January 27.
noon, Faculty Club.
Hopefully this is IT!
Please RSVP ASAP to PHY@SAIL. Thanks.
∂19-Jan-88 0913 JSW Displaying extended characters
∂19-Jan-88 0236 rms@wheaties.ai.mit.edu Displaying extended characters
Received: from frosted-flakes.ai.mit.edu ([128.52.32.19]) by SAIL.Stanford.EDU with TCP; 19 Jan 88 02:36:30 PST
Received: by frosted-flakes.ai.mit.edu; Mon, 18 Jan 88 23:59:50 EST
Date: Mon, 18 Jan 88 23:59:50 EST
From: rms@wheaties.ai.mit.edu (Richard Stallman)
Message-Id: <8801190459.AA00610@frosted-flakes.ai.mit.edu>
To: JSW@sail.stanford.edu
In-Reply-To: Joe Weening's message of 18 Jan 88 2231 PST <8801190633.AA28483@prep.ai.mit.edu>
Subject: Displaying extended characters
Very general code for this has already been written,
and I will put it into Emacs version 19.
I am not considering any such severe changes for version 18
maintenance releases.
∂19-Jan-88 1006 VAL Ed Brink
Ed Brink expects from you some sort of reaction to the progress report he sent
you earlier this month, and he asked me to remind you about it. Here is his
summary of what he'd like you to do:
> He has an official recommendation-letter form (or should have, if they didn't
> send it to Texas; I put it in his box in late December). So I'm expecting he
> will act on it one way or another, and if it makes sense to tell me to do
> something, he will (I presume) do so. I'd like some sort of clue to what state
> I'm in; if he really likes the work, that's one thing, and if he hates it,
> that's another. In either of those cases I don't have to do anything now, but
> knowing which it is will help me start preparing for the future. In the middle
> case, if I need to do more on the project, the sooner I know the better I can
> try to plan for it.
> So: I'd like him to write the letter and if possible let me know its general
> content. I'd also like a grade in CS399, but since it's not on my proposal any
> more I don't know how urgent that is.
My summary of the progress he's made:
The assignment was to implement the inverse method. He spent a lot of time
studying the inverse method (as described in my paper) and MRS, and documenting
them more formally. But he hasn't really done any serious coding so far.
∂19-Jan-88 1233 rivin@Gang-of-Four.Stanford.EDU re↑17vised proposal
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 12:33:32 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02668; Tue, 19 Jan 88 12:33:49 pst
Date: Tue, 19 Jan 88 12:33:49 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801192033.AA02668@Gang-of-Four.Stanford.EDU>
To: jmc@sail, rpg@sail, edsel!arg@labrea, les@sail
Subject: re↑17vised proposal
Here goes...
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
This has been proceeding at a good pace, after some intial delay
setting up the Stanford-Lucid computer link
o Lucid Common Lisp has been implemented (March 87)
o QLET T has been implemented (July 87)
o QLAMBDA T has been implemented (December 87)
o Several convenient locking primitives have been designed and
implemented (December 87)
o Dynamic variables have been implemented using the deep binding
strategy (January 88)
o Several task-scheduling algorithms have been implemented and tested
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
QLISP programs have been showing speedups of greater than 3x on the
four processors we have. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
In the current Lucid implementation, it takes about .3 milliseconds to spawn
a process, so as long as the granularity of a problem is considerably greater
than that, good speedups can reasonably be expected. The number of
active processes should be no more than around a thousand and certainly
no less than the number of processors in order for reasonable speedups to
be achievable. In many of the applications below, these conditions have
been met.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming.
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort (August 87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented (December 1987)
The Next Eighteen Months (the dates below are targets for completion, work
is predicated on the proposed increased (a) and originally requested (b)
levels of funding)
oo QLISP implementation on the Alliant FX/8 (a)
It is anticipated that QLISP implementation effort will continue
apace, and will coexist with maintenance of the system.
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
(June 88)
o Non-local exits via CATCH and THROW will be implemented (March 88)
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed. (September 88)
o Better performance-monitoring tools will be designed. (September 88)
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
(January 89)
o A more usable program development environment will be designed.
(prototype system by March 89)
oo QLISP implementation on the Alliant FX/8 (b)
It is anticipated that QLISP implementation effort will continue
apace, and will coexist with maintenance of the system.
o Non-local exits via CATCH and THROW will be implemented (March 88)
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
(August 88)
o Some work will continue on task-scheduling strategies.
o Some performance-monitoring tools will be designed. (January 89)
o System tuning and improved debugging aids. (January 89)
oo Applications Development (a and b)
Experiments will be conducted with implementing medium-to-large
systems.
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place (Continuous through
the next eighteen months)
o Other application domains in symbolic processing will be investigated
(continuous)
oo Miscellaneous (a)
The Alliant FX/8 is limited both in computing power (at most
eight processors) and in generality of code written for it (the
code is likely to not be easy to port to other multiprocessors).
These problems will be addressed.
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having QLISP
available on other machines will make it more widely available to
experimentation by DARPA research community (perhaps get another
machine by August 88)
o Porting to Encore under MACH will be evaluated (by August 88)
o Distributed extensions under MACH will be evaluated (by January 89)
o Multitasking will be evaluated under MACH, so that parallel programs
can be run on uniprocessors. (by January 89)
∂19-Jan-88 1245 Qlisp-mailer meeting agenda,etc
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 12:44:55 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02687; Tue, 19 Jan 88 12:45:18 pst
Date: Tue, 19 Jan 88 12:45:18 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801192045.AA02687@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: meeting agenda,etc
Some urgent personal matters will necessitate my absence (physical,
not electronic) for the next couple of days. In particular I won't be
here on wednesday. This probably should affect the agenda, as far as
the discussion of the next eighteen months is concerned.
∂19-Jan-88 1439 AIR qlisp, gcd
I decided to try one more approach to polynomial gcds. Unfortunately, I bumped
into some new bugs, therefore there will be few more days before I send you
my report.
Arkady
∂19-Jan-88 1601 MPS darpa
Jack Schwartz of DARPA called - 16:01. He would like
you to call him. His number is 202-694-5922
Pat
∂19-Jan-88 1614 BEDIT@Score.Stanford.EDU Summary of November computer charges.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 16:14:39 PST
Date: Tue 19 Jan 88 15:42:27-PST
From: Billing Editor <BEDIT@Score.Stanford.EDU>
Subject: Summary of November computer charges.
To: MCCARTHY@Score.Stanford.EDU
Message-ID: <12367950726.12.BEDIT@Score.Stanford.EDU>
Dear Mr. McCarthy,
Following is a summary of your computer charges for November.
Account System Billed Pct Cpu Job Disk Print Adj Total
JMC SAIL 2-DMA705 100 140.97 119.36 ***.** .00 5.00 2642.37
MCCARTHY SCORE 2-DMA705 100 .00 .00 6.88 .00 5.00 11.88
MCCARTHY SUSHI SUSHI 100 .00 .00 .00 .00 .00 .00
Total: 140.97 119.36 ***.** .00 10.00 2654.25
University budget accounts billed above include the following.
Account Principal Investigator Title
2-DMA705 McCarthy N00039-84-C-0211
The preceding statement is a condensed version of the detailed summary sheet
sent monthly to your department.
Please verify each month that the proper university budget accounts are paying
for your computer usage. Please also check the list of account numbers below
the numeric totals. If the organizations/people associated with that account
number should NOT be paying for your computer time, send mail to BEDIT@SCORE.
Please direct questions/comments to BEDIT@SCORE.
-------
∂19-Jan-88 1639 MPS phone call
Yvette - 3-2266 - would like you to call her regarding
a personnel matter.
pat
∂19-Jan-88 2054 Mailer re: peace talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 20:50:37 PST
Date: Tue 19 Jan 88 20:46:08-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: re: peace talks
To: CHIN@SUMEX-AIM.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12367726751.15.CHIN@SUMEX-AIM.Stanford.EDU>
Message-ID: <12368006008.26.TEICH@Sushi.Stanford.EDU>
1) I am not an apologist for the administration. I think it has done
some correct and some incorrect things.
2) You didn't respond to anything else in the statement other than
that one sentence. That sounds like the typical apologist for the
Sandinistas. All rhetoric, little facts. Could you please responde to
what I saw as a prevalent bias. If you can't, why do you hold your views?
If you can, maybe you can convince me.
3) And another thing you could comment on, what do you think about the
fact that the same day Ortega said he'd talk to the rebels about cease-fires
his government arrested six opposition leaders. Some were charged with
meeting the contra leaders, others were arrested for voicing sympathy for
the rebels.
And on the general tangent of US intervention, how much to all of you
think that the US govt. support of the Afghan rebels is responsible for
helping them survive this long? Do anyone agree or disagree with the
statement (not necessarily my view) that that military aid contributed
to the Soviet's plans to withdraw from that country?
Finally, as I've stated in previous messages, there are a lot of
similarities between El Salvador and Nicaragua. Both countries are
run badly, the major change is the govt in power. This single issue
changes the USSR's and US's views to the other side in each place.
Neither side is perfectly good or evil. I'm tired of both sides
of the bboard discussion attributing those same silly views to the
opposing side of the argument. Liam and very few others admit that, though
the side they believe has problems, they think it's the best option. The
rest of you agnostics and athiests seem to be claiming god is on your side...
david
-------
∂19-Jan-88 2108 Mailer re: peace talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 21:08:49 PST
Date: Tue 19 Jan 88 21:04:29-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: re: peace talks
To: CHIN@SUMEX-AIM.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12367736371.15.CHIN@SUMEX-AIM.Stanford.EDU>
Message-ID: <12368009348.26.TEICH@Sushi.Stanford.EDU>
Thanks for posting some facts in your other message. First, I do know
about the papers in El Salvador. Second, I know that the man was murdered,
and the assasinations are more frequent in El Salvador. But, from what I've
read, the death squads haven't been allied with the govt. for a number of
years. It is pitiful that the govt. has only taken a weak stand against
them, but the ouster of D'Aubison (spelling?) is believed to have removed
the links. Third, I've not yet seen any accurate count of the number
of civilians killed by the death squads or by the communist guerrillas.
I've read about a number of attacks on civilians by both sides. The same
goes for Nicaragua. The contras do have support, but mainly in the country,
where many believe the Sandanistas have ignored promised land reforms.
The death squads killed many people, and are still active. But they are
not any where close to being as prevelant in the last five years.
If we tie more of our aid to outright demands for better govt control,
the number would get smaller or we could remove aid.
Also, the contra's are always portrayed as ex-guardsmen. I read an
interview last summer with a high level contra who said he was in the
Sandanista movement until after the revolution. he felt that the
Sandanistas then proceeded to foul things up. The article said he wasn't
the only person with that background.
As further review, reread some of the things that happened after El
Salvador's first election. First, the land reforms were halted primarily
by pressure from the far left. That pressure was, surprisingly, larger
than the complaints from the far right.
Yes, El Salvador is worse than Nicaragua, and use to be much worse.
If we'd apply more economic pressure, it would get better or we should
get out. But, in Nicaragua, we have no "economic" presence, only military.
We can't affect them the same way, and they know it.
The report quickly mentioned rumours of Sandanista torturing in their
prisons. They spent a lot of time on the Contra's. They spent a lot of time
on the rumours of torture in El Salvadorian prisons. They didn't even
mention the El Salvadorian rebels. Rumors of atrocities in both country's
jails seem to be substantiated though, again, El Salv. has worse problems.
But the rebels in ES have also commited many atrocities, some say more
than the contra's have done.
El Salvador is wors than Nicaragua. But combining the many sources, it
seems to be not as great a difference as AI states. When they spent time
on one side of an issue and ignore the other, even is the side they spend
time on has more problems, I call that biased.
david
-------
∂19-Jan-88 2313 mcvax!litp!queinnec@uunet.UU.NET IWoLES proceedings
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 23:13:04 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA01723; Wed, 20 Jan 88 02:13:04 EST
Received: by mcvax.cwi.nl; Wed, 20 Jan 88 05:42:08 +0100 (MET)
Received: by inria.inria.fr; Tue, 19 Jan 88 22:33:39 -0100 (MET)
Received: by litp.unip6-7.fr (5.51/5.17)
id AA06238; Tue, 19 Jan 88 16:20:10 +0100
Date: 19 Jan 1988 16:06-EST
From: mcvax!inria.inria.fr!queinnec@uunet.UU.NET
Subject: IWoLES proceedings
To: jmh@next.com, jmc@sail.stanford.edu, bobrow.pa@xerox.com,
Gregor.pa@xerox.com, willc%tekchips%Tektronix.CSNET@RELAY.CS.NET,
rpg@sail.stanford.edu, inria!inria.inria.fr!pc@uunet.UU.NET,
inria!inria.inria.fr!pg@uunet.UU.NET,
inria!inria.inria.fr!devin@uunet.UU.NET,
inria!inria.inria.fr!kahn@uunet.UU.NET, sanson!crcge1@uunet.UU.NET,
ukc!hlh!bath63!ma_jap@uunet.UU.NET
Cc: inria!inria.inria.fr!queinnec@uunet.UU.NET
Message-Id: <569603189/queinnec@litp>
I just remind you that we need your paper for IWoLES proceedings
before January, 22th. You can send it to me by Email, I will
typeset them directly. Thank you and looking forward to seeing
you in Paris.
Christian Queinnec
∂19-Jan-88 2359 Mailer The Narrow Interpretation Of The Constitution
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 23:59:08 PST
Date: Tue 19 Jan 88 23:54:50-PST
From: Mike Peeler <G.MDP@Score.Stanford.EDU>
Subject: The Narrow Interpretation Of The Constitution
To: PALLAS@Sushi.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU, JMC@Sail.Stanford.EDU
In-Reply-To: <12367395549.10.PALLAS@Sushi.Stanford.EDU>
Message-ID: <12368040361.11.G.MDP@Score.Stanford.EDU>
Hi joe,
As I recall, the Constitution limits Congress to the powers
enumerated, and explicitly does not so limit the President. Any
evidence to affirm or deny this recollection is welcome.
Cheers,
Mike
-------
∂20-Jan-88 0157 Mailer re: peace talks
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 01:57:01 PST
Date: Wed, 20 Jan 88 01:56:20 PST
From: Homer Chin <CHIN@SUMEX-AIM.Stanford.EDU>
Subject: re: peace talks
To: TEICH@Sushi.Stanford.EDU
cc: JMC@Sail.Stanford.EDU, su-etc@Sail.Stanford.EDU
In-Reply-To: <12368009348.26.TEICH@Sushi.Stanford.EDU>
Message-ID: <12368062480.19.CHIN@SUMEX-AIM.Stanford.EDU>
Teich writes:
> El Salvador is wors than Nicaragua. But combining the many sources, it
>seems to be not as great a difference as AI states. When they spent time
>on one side of an issue and ignore the other, even is the side they spend
>time on has more problems, I call that biased.
The problem is not with Amnesty International. The problem is with
your "many sources". From reading newspaper coverage of Central
America, it is understandable how you might conclude that: "El Salvador
is worse than Nicaragua. But combining the many sources, it seems to
be not as great a difference as AI states."
A study of Central American News coverage showed:
* More than 80% of articles published during the first six weeks after
the signing of the peace plan focused entirely or almost entirely on
Nicaragua.
* Sources quoted for comments and analysis were almost always either
administration officials, contra leaders or representatives of other
conservative organizations that advocate military resolutions to the
conflict.
* While newspapers published numerous articles critical of the
Sandanistas and their efforts to comply with the peace plan, serious
human rights problems and violations of the plan by the governments of
El Salvador, Honduras and Guatemala were largely unreported.
During the 90 days following the signing of the peace plan,
Nicaragua's appointment of its National Reconciliation Commission, the
reopening of the opposition newspaper La Prensa and Radio Catolica,
offers of a cease-fire--and the Reagan Administration's skepticism
about it all--received extensive, prominent coverage. The failure of
Honduras and Guatemala to take similar steps received no coverage.
The governments of El Salvador, Guatemala and Honduras all have
allowed serious human violations to continue. Prominent government
critics have been arrested and tortured in El Salvador, and reputed
death squad killers have been freed. Honduras has allowed the contras
to continue to use its territory to stage attacks on Nicaragua, and
Guatemala has broken off talks with its rebels. None of those
incidents received significant coverage in the U.S. press.
We could go on and on about manipulation of the media by the
administration, and the fabrication of news whenever something
positive happens in Nicaragua: such as having the press chase after
phantom MIGs just when Nicaragua has elections (remember that?).
However, you might read a book written by Edgar Chamorro, a Contra
leader and press spokesperson from 1982 to 1984, entitled
"Packaging the Contras". It will give you some idea of just how
extensive the administration's campaign of disinformation has been.
-------
∂20-Jan-88 0907 MPS lunch
Mr.Cohen will meet you at the same place at 1:15
today.
Pat
∂20-Jan-88 1059 BSCOTT@Score.Stanford.EDU [PUCCI@A.ISI.EDU: Re: [Betty Scott <BSCOTT@SCORE.STANFORD.EDU>: N00039-84-C-0211 Budget Justification for Extension]]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 10:59:22 PST
Date: Wed 20 Jan 88 10:55:06-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: [PUCCI@A.ISI.EDU: Re: [Betty Scott <BSCOTT@SCORE.STANFORD.EDU>: N00039-84-C-0211 Budget Justification for Extension]]
To: DCL@Sail.Stanford.EDU, ZM@Sail.Stanford.EDU, CLT@Sail.Stanford.EDU,
JMC@Sail.Stanford.EDU, LES@Sail.Stanford.EDU
Message-ID: <12368160560.33.BSCOTT@Score.Stanford.EDU>
Here is a message I received this morning from John Pucci. The information
he needs for each Task is expense to date, and funds necessary to complete the
tasks.
To David Luckham: Would you please respond directly to John Pucci, with copy
to me.
To Zohar Manna, John McCarthy, Carolyn Talcott and Les Earnest: Sharon and I
will work on information for your tasks, and will discuss the information with
you before sending to John Pucci.
Betty
---------------
Return-Path: <PUCCI@A.ISI.EDU>
Received: from A.ISI.EDU by SCORE.STANFORD.EDU with TCP; Wed 20 Jan 88 07:54:15-PST
Date: 20 Jan 1988 10:54:21 EST
From: PUCCI@A.ISI.EDU
Subject: Re: [Betty Scott <BSCOTT@SCORE.STANFORD.EDU>: N00039-84-C-0211 Budget Justification for Extension]
To: BSCOTT@SCORE.STANFORD.EDU
cc: PUCCI@A.ISI.EDU
In response to your message sent Tue 19 Jan 88 14:08:21-PST
Betty,
Sorry to hear about the death in your family. I talked to Julio
this morning and left your message on his desk. He is working in
a different office but he sometimes comes in to work on his
contracts.
I need some information from you on some of the tasks on the
contract. DARPA is having one of its occasional budget drills
and we need to know and obligation and expenditure information
on the following tasks:
Task 2 Prof. Luckham Adv. Prog. Environments
Task 3 Prof. Manna Deductive Programming
Task 7 Prof. Manna TABLOG
Task 8 Prof. McCarthy QLISP
Task 12 Prof. Luckham Adv. Devel. Environments
Task 13 Dr. Talcott Math. Theory of Computation
Task 15 Prof. Manna Deductive Programming Synthesis
I need this information within the next day or so. Sorry about
the short notice.
Thanks,
John
-------
-------
∂20-Jan-88 1411 PHY
Please let me know if you will be able to meet with the senior members
of the Theory group of Computer Science
Wednesday, January 27, noon, Faculty Club.
Thanks, Phyllis
∂20-Jan-88 1458 Qlisp-mailer qlisp documentation
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 14:58:19 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00666; Wed, 20 Jan 88 14:58:39 pst
Received: by labrea.Stanford.EDU; Wed, 20 Jan 88 14:58:19 PST
Received: from bhopal.lucid.com by edsel id AA16876g; Wed, 20 Jan 88 14:52:31 PST
Received: by bhopal id AA21370g; Wed, 20 Jan 88 14:55:49 PST
Date: Wed, 20 Jan 88 14:55:49 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801202255.AA21370@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: qlisp documentation
For the benefit of those Qlisp users who were not at today's Qlisp meeting, I
have put together some Qlisp documentation describing the features in the
current Qlisp implementation. It can be found in the file /qlisp/qlisp.doc,
which I'll try to keep somewhat up to date.
Ron
∂20-Jan-88 1609 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
We will meet on Fridays at 3:15, in MJH301. My apologies to those who voted for
Wednesdays.
HIERARCHIC AUTOEPISTEMIC THEORIES FOR NONMONOTONIC REASONING
Kurt Konolige (KONOLIGE@BISHOP.AI.SRI.COM)
SRI International
Friday, January 29, 3:15pm
Nonmonotonic logics are meant to be a formalization of nonmonotonic
reasoning. However, for the most part they fail to capture in a
perspicuous fashion three of the most important aspects of such
reasoning: the explicit computational nature of nonmonotonic inference,
the assignment of preferences among competing inferences, and the
specification of how facts with the same semantic content can be used
differentially in inference. We propose a new method of nonmonotonic
reasoning in which the notion of inference from specific bodies of
evidence plays a fundamental role. The formalization is based on
autoepistemic logic, but introduces additional structure, a hierarchy of
evidential subtheories. The method offers a natural formalization of
many different applications of nonmonotonic reasoning, including
reasoning about action, speech acts, belief revision, and various
situations involving competing defaults.
∂20-Jan-88 1635 cheriton@Pescadero.stanford.edu Fac. Senate and the Decline of Western Culture
Received: from Pescadero (Pescadero.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 20 Jan 88 16:35:37 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA05699; Wed, 20 Jan 88 16:35:29 PST
Date: Wed, 20 Jan 88 16:35:29 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801210035.AA05699@Pescadero>
To: jmc@Sail.Stanford.EDU
Subject: Fac. Senate and the Decline of Western Culture
For what little it is worth, I find the proposed watering down of
the Western Culture program in favor of the current faddish books
based on the sex and pigmentation of the authors pretty disgusting.
I hope you will oppose this craziness. I cant imagine the university
education we offer being taken seriously if we allow it to be manipulated
by the politically active minority whose left-wing political objectives
take precedent over their education. From the Daily article, it seems
liek Chase has a far more reasonable alternative.
David Cheriton
∂20-Jan-88 2313 cheriton@Pescadero.stanford.edu re: Fac. Senate and the Decline of Western Culture
Received: from Pescadero (Pescadero.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 20 Jan 88 23:13:07 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA08570; Wed, 20 Jan 88 23:13:05 PST
Date: Wed, 20 Jan 88 23:13:05 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801210713.AA08570@Pescadero>
To: JMC@sail.stanford.edu
Subject: re: Fac. Senate and the Decline of Western Culture
Oops! I guess I did think you were still in the Senate.
∂21-Jan-88 0949 MPS Insight Magazine
Rick Lipkin (202-636-2948) got your name from Marvin Minsky.
He is putting together an article about AI to be published in
the above magazine. He realizes your busy but would appreciate
about 5 minutes of your time to discuss AI - history, trends,
research, etc.
Pat
∂21-Jan-88 1043 LOGMTC-mailer Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 10:42:30 PST
Date: Thu 21 Jan 88 10:35:23-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
cc: csd@Sushi.Stanford.EDU, logmtc@Sail.Stanford.EDU
Message-ID: <12368419114.32.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
January 22: Prof. Vaughan Pratt (Stanford Univ.),
"An Introduction to Dynamic Logic"
January 29: Dr. Leslie Lamport (DEC-SRC),
"What Good is Temporal Logic?"
Upcoming talks this quarter by John Mitchell, Joe Halpern, Luca Cardelli,
Joseph Goguen, Phokion Kolaitis, and Zohar Manna.
-------
∂21-Jan-88 1140 helen@psych.Stanford.EDU Hi there
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 11:40:11 PST
Received: by psych.Stanford.EDU (3.2/4.7); Thu, 21 Jan 88 11:39:54 PST
Date: Thu, 21 Jan 88 11:39:54 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Hi there
I'm running a subject who arrived late. I may be 5 minutes late
to Fac Club. But I'll be there! See you soon.
-helen
∂21-Jan-88 1628 JSW GNU Emacs
I tried a quick hack to make GNU Emacs display extended ASCII characters
on DMWAITS terminals, but it didn't work. I think it is because for each
such character I had it put two characters in the output stream to the
terminal (as is necessary), and this confused it about where the cursor
position should be. Since my understanding of the Emacs internals is very
limited, it may still be possible but I'd rather not spend the time to
figure out how to do it.
∂21-Jan-88 2041 JSW Some benchmark results
To: edsel!arg@LABREA.STANFORD.EDU, RPG@SAIL.Stanford.EDU,
edsel!jonl@LABREA.STANFORD.EDU, JDP@SAIL.Stanford.EDU,
rivin@Gang-of-Four.Stanford.EDU, JMC@SAIL.Stanford.EDU
Here are the results of a few tests I ran this afternoon on Gang-of-Four.
The goal was to measure differences in performance of ordinary Lisp
operations in the successive implentations of Qlisp, to see if supporting
parallelism causes any basic operations to slow down. The following
versions of Lisp and Qlisp were tested:
lisp 29 Jul 87 Uniprocessor Lisp
oldest-qlisp 29 Jul 87 Qlisp without cons-lock
old-qlisp 3 Dec 87 Qlisp with cons-lock
qlisp 6 Jan 88 Qlisp with improved process handling
new-qlisp 12 Jan 88 Qlisp with deep binding
I ran three of the Gabriel benchmarks, with no modifications to the code.
TAK tests only function calls and simple arithmetic. STAK tests these and
also special variable binding. BOYER mostly tests consing, though it uses
special variables (in some cases, where lexical variables would suffice).
Here are the results:
TAK STAK BOYER
lisp .540 1.97 25.0 (24.4-25.5)
oldest-qlisp .539 1.96 26.0 (25.8-26.2)
old-qlisp .539 2.03 26.1 (25.5-26.6)
qlisp .539 2.02 26.3 (25.7-26.8)
new-qlisp .539 4.81 40.0 (39.3-40.6)
For TAK and STAK, I compiled the program and then ran it five times. The
first run generally took a few milliseconds longer than the rest; then the
sucessive runs very consistently gave the numbers shown.
Running BOYER always caused garbage collection. With the default memory
size, it garbage collected either once or twice, which of course made a
noticeable difference in the timings. Therefore I ran it until there were
three runs each having two garbage collections, and the table shows the
mean of those times and the range they were in.
Some conclusions one can draw from these numbers are:
1. The basic Lisp performance has stayed the same for things like arithmetic
and function calls. We could use Qlisp as a single processor Lisp (telling
the machine to run it on a single CE) and not have to maintain uniprocessor
Lisp as a separate program, without losing very much in performance.
2. It is not clear whether the cons-lock adds noticeable overhead to a
program using a single processor. If it did, old-qlisp would be slower
than oldest-qlisp on BOYER, but they appear quite close.
3. Deep binding currently is very expensive.
The two main unanswered questions are:
1. Why does STAK get slower going from oldest-qlisp to old-qlisp? This is
where the implicit cons-lock was added, but the program does no consing.
2. Why is BOYER slower in oldest-qlisp than in lisp? The cons-lock had
not yet been added at this point, though perhaps consing had to slow down
for other reasons. Also, oldest-qlisp provides less free storage than lisp
as a default (perhaps it needs to pre-allocate more for various things).
∂21-Jan-88 2258 paulf@umunhum.stanford.edu Re: industrial lecturers
Received: from umunhum.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jan 88 22:58:14 PST
Received: by umunhum.stanford.edu; Thu, 21 Jan 88 22:55:40 PST
Date: Thu, 21 Jan 88 22:55:40 PST
From: Paul Flaherty <paulf@umunhum.stanford.edu>
Subject: Re: industrial lecturers
To: JMC@sail.stanford.edu
Charlie Bass, of Ungermann - Bass. A great lecturer, who has a lot to say
about networking philosopy.
-=paulf
∂22-Jan-88 0248 Mailer Re: Bimonthly
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 02:48:01 PST
Date: Fri 22 Jan 88 02:43:34-PST
From: Mike Peeler <G.MDP@Score.Stanford.EDU>
Subject: Re: Bimonthly
To: JMC@Sail.Stanford.EDU
cc: T.TWINKIE@Lear.Stanford.EDU, gay@Lear.Stanford.EDU,
su-etc@Sail.Stanford.EDU, Rokicki@Sushi.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Wed 20 Jan 88 18:03:00-PST
Message-ID: <12368595366.17.G.MDP@Score.Stanford.EDU>
I'm not sure it was ever quite that clean. Clouding the biennial/
semiannual picture is biannual, which is a synonym for the latter,
not the former. Well, I guess biannual is just an abomination.
Anyway, my handy Oxford American is less non-prescriptive:
bimonthly ... 2. happening twice a month.
>>> Careful writers do not use bimonthly in this
sense. They use semimonthly.
-------
∂22-Jan-88 0700 JMC
squires
∂22-Jan-88 0900 JMC
Aldo Test
∂22-Jan-88 0923 paulf@umunhum.stanford.edu re: industrial lecturers
Received: from umunhum.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jan 88 09:22:55 PST
Received: by umunhum.stanford.edu; Fri, 22 Jan 88 09:20:22 PST
Date: Fri, 22 Jan 88 09:20:22 PST
From: Paul Flaherty <paulf@umunhum.stanford.edu>
Subject: re: industrial lecturers
To: JMC@sail.stanford.edu
He taught EE384 with John Gill last year. At the time, he said that he enjoyed
lecturing at Stanford because he was able to recruit people for Ungermann -
Bass more effectively that way. I have the number for his receptionist around
here somewhere...
-=paulf
∂22-Jan-88 0936 ULLMAN@Score.Stanford.EDU Re: industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 09:36:23 PST
Date: Fri 22 Jan 88 09:32:04-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: Re: industrial lecturers
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 21 Jan 88 22:20:00-PST
Message-ID: <12368669730.16.ULLMAN@Score.Stanford.EDU>
I have discussed a visit with Jim Gray. He would like to teach a
course for us this Spring, and he thinks Tandem will give him the
time to do so gratis. He is also looking for a closer relationship
with us, perhaps being on campus 2 days a week indefinitely.
---jdu
-------
∂22-Jan-88 1010 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: industrial lecturers
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 10:10:30 PST
Date: Fri, 22 Jan 88 10:10:16 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: industrial lecturers
To: JMC@SAIL.STANFORD.EDU
cc: CBarsalou@Score.Stanford.EDU, ark@SAIL.STANFORD.EDU,
mcvax!margaux.inria.fr!litwin@uunet.uu.net,
"*PS:<WIEDERHOLD>LITWIN.PEOPLE.1"@SUMEX-AIM.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu, 21 Jan 88 22:20:00 PST
Message-ID: <12368676686.57.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
I am making arrangements for a possible sabbatical stay at SRI mainly
for Witold Litwin, from INRIA. He is mainly a researcher (file access,
distribute databases) and has co-managed a major French project.
If things work out (p=60%) he could do an industrial lectureship in
any of the quarters. I will get his vitae to you, and a course
description as soon as I can get one.
Gio
-------
∂22-Jan-88 1027 ULLMAN@Score.Stanford.EDU re: industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 10:27:35 PST
Date: Fri 22 Jan 88 10:23:11-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: re: industrial lecturers
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 22 Jan 88 10:06:00-PST
Message-ID: <12368679036.42.ULLMAN@Score.Stanford.EDU>
He has no email. Try 408-943-6919, or TAndem at 19333 Vallco Pkwy,
Cupertino 95104
---jeff
PS: What is your opinion of Phokion Kolaitis?
-------
∂22-Jan-88 1031 @Score.Stanford.EDU:ZM@SAIL.Stanford.EDU Re: industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 10:31:15 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 22 Jan 88 10:26:50-PST
Date: 22 Jan 88 1030 PST
From: Zohar Manna <ZM@SAIL.Stanford.EDU>
Subject: Re: industrial lecturers
To: JMC%SAIL.Stanford.EDU@Score.Stanford.EDU
[Reply to message sent: 21 Jan 88 2220 PST]
John,
As the chairman of the Curriculum Comm.this year, I would like to make sure
that any industrial course is "approved" by the committee.
(This year we had a major disaster with Lamport's course...)
Thanks Zohar
∂22-Jan-88 1058 helen@psych.Stanford.EDU Most enjoyable
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 10:58:13 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 22 Jan 88 10:57:53 PST
Date: Fri, 22 Jan 88 10:57:53 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Most enjoyable
Cc: helen@psych.Stanford.EDU
I really enjoyed our lunch conversation yesterday and look forward
to doing it again sometime. In particular, I'd like to find out more
about your view of Psychology. From some su-etc remarks of yours, I
had assumed that you consider us a bunch of shrinks. But your comments
yesterday indicate that you in fact know the work we do. The experiment
I told you about is problematic for the reasons you alluded to (and more)
and isn't exactly my favorite. So, I'd like to tell you about some of the
other stuff we do (and see if I can change your mind...)
So anyway, until then, cheerio and all that.
-helen
∂22-Jan-88 1153 VAL
Can we meet some time after 3pm, instead of 1:30 today?
∂22-Jan-88 1227 helen@psych.Stanford.EDU re: Most enjoyable
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 12:27:08 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 22 Jan 88 12:26:50 PST
Date: Fri, 22 Jan 88 12:26:50 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: Most enjoyable
Ok, next Thursday at noon sounds great. Shall we meet in front of MJH?
-helen
∂22-Jan-88 1209 VAL re: reply to message
[In reply to message rcvd 22-Jan-88 12:08-PT.]
Let's make it 3.
∂22-Jan-88 1236 CLT kronos
we have tickets
8pm Herbst theater
we should leave a little before 7.
∂22-Jan-88 1252 FLAVIU@IBM.COM
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Jan 88 12:51:46 PST
Date: 22 Jan 88 12:03:13 PST
From: Flaviu Cristian <FLAVIU@ibm.com>
To: JMC@SAIL.stanford.EDU, Hennessy@sierra.stanford.EDU
Dear Professors McCarthy and Hennessy,
My colleague Joe Halpern passed me a message from John McCarthy
to CS faculty concerning a search for industrial lecturers. I also
saw an add in the January issue of IEEE Computer for similar positions,
so I am writting to both of you.
I would be interested in teaching a course on
distributed fault-tolerant computing in 1988. The lenght
of the course can be adapted to your needs. A course description
is appended. I would prefer fall/winter 88, since untill June 88
I have to travel a week or two each month to Washington DC, were
I am technical leader for an IBM project to design a new (highly
available) air traffic control system for the FAA. Thus,
if you need somebody before summer, I could probably come
only once or twice a month.
Hope to hear from you soon.
Flaviu Cristian
--------------------------------------------------------------
COURSE ON DISTRIBUTED FAULT-TOLERANT COMPUTING
Dr. Flaviu Cristian
IBM Almaden Research Center
650 Harry Road
San Jose, Ca 95120-6099
tel. (408) 927-1757
OVERVIEW:
With the ever increasing dependence on computing services, the
availability of computing systems in the presence of component
failures becomes of paramount importance. This course, designed for
MS and PhD students in Computer Science and Electrical Engineering,
surveys the state of the art in commercial single-fault tolerant
systems design, presents new research results concerning the design of
systems capable of tolerating arbitrary numbers of failures, and
disscusses a number of open problems.
Fault-tolerant systems differ from ordinary systems in that they
undergo specified state transitions not only in response to standard
events triggered by human users or changes in a monitored physical
environment, but also in response to failure events caused by adverse
mechanical, chemical, electro-magnetic and human processes. Although
the architecture of such systems can be quite diverse, the goal of the
course is to present in a coherent pedagogical manner the fundamental
concepts and techniques which underlie their design. These are
illustrated with examples from commercially available systems and
research prototypes - primarily drawn from DEC, IBM, Stratus, and
Tandem.
COURSE CONTENTS
INTRODUCTION
Basic concepts and terminology: specification, semantics, correctness,
robustness, exception, failure, error, fault, atomicity.
Fault-avoidance and fault-tolerance: two complementary approaches for
ensuring high system dependability.
Exception handling: detection, recovery, masking, and propagation;
existing language mechanisms are described and contrasted.
Specifying and proving the correctness of robust programs
Specification and correctness proofs for programs tolerant of
hardware failures and crashes
Software-fault tolerance: state of the art and recent experiments
CONCEPTS THAT HELP UNDERSTAND EXISTING COMMERCIAL SINGLE-FAULT
TOLERANT SYSTEMS
Basic hardware units of failure/error confinement/replacement
Fail-stop, fail-fast and TMR processors, reliable storage and disks
Hardware failure detection and masking
Basic ideas in error detecting/correcting codes, their use and their
effectiveness.
Redundant data structures: design principles and examples.
The replicated client/server software model
Process pairs, reliable communication protocols among process pairs.
Software module failure detection and masking
Location transparent naming
Transactions, the atomic commit problem, the two phase commit
protocol and variants.
EXAMPLES OF COMERCIAL SINGLE-FAULT TOLERANT SYSTEMS
The Tandem NonStop System.
The Stratus Continuous Processing System.
The DEC VAX-cluster system.
CONCEPTS THAT HELP
UNDERSTAND AND BUILD MULTIPLE-FAULT TOLERANT SYSTEMS
Asynchronous and synchronous communication environments
Diffusion based synchronous atomic broadcast: specification and design
of a family of protocols tolerant of increasingly complex failure
classes.
Acknowledgement based asynchronous atomic broadcast tolerant of
partition failures
Fault-tolerant clock synchronization: existing approaches are described
and contrasted. External clock synchronization.
The processor group membership problem: reaching agreement on the
identity of all correctly functioning processors in the presence
of any number of failures and joins
Synchronous protocols for solving the processor membership problem
Asynchronous protocols for solving the processor membership problem
in the presence of partition failures
Process groups, process group membership, group atomic broadcast and
join protocols
Tight synchrony versus lose synchrony of process groups
Network partition detection and recovery. The problems to be solved and
the existing optimistic and pessimistic approaches are presented and
contrasted
Using synchronous and asynchronous distributed storage to achieve high
availability of computing services
EXAMPLES OF SYSTEMS TOLERANT OF MULTIPLE-FAILURES
The IBM highly available system prototype.
THE LECTURER
Dr. Flaviu Cristian is a computer scientist at the IBM Almaden
Research Laboratory in San Jose, California. After carrying out
research on the specification, design, and verification of
fault-tolerant software in France in England, he joined the IBM San
Jose Research Laboratory in 198. Since then he has worked on the
design of several fault-tolerant distributed systems and algorithms.
He is now involved with the design of a new Air Traffic Control System
for the FAA which must satisfy very stringent availability
requirements. Dr. Cristian has written numerous articles. He has
extensively lectured in the USA, in Europe, in Japan, and Latin
America. He has reviewed and consulted for several fault-tolerant
distributed system designs, both in Europe and in the American
divisions of IBM. Dr. Cristian was chairman of the First IBM
Symposium on High Availability/Horizontal Growth, was program co-chair
of the 17th International Symposium on Fault-Tolerant Computing, and
has served on the program committees of other American and
International symposia.
∂22-Jan-88 1412 ULLMAN@Score.Stanford.EDU Jim Gray
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 14:11:55 PST
Date: Fri 22 Jan 88 14:07:35-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: Jim Gray
To: nilsson@Score.Stanford.EDU, reges@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, jlh@VSOP.Stanford.EDU
Message-ID: <12368719888.45.ULLMAN@Score.Stanford.EDU>
There has been a further development. Jim tells me he is taking
a leave of absence from Tandem for next quarter. He wants to
have an office here and teach a course on transaction management,
working on notes for a book.
He is willing to teach on TV.
I suggest we:
1. Agree to this.
2. Find a TV slot for the spring, preferably TuTh.
3. Find him an office, preferably in MJH.
4. Offer to pay him a reasonable salary for the quarter.
I think we have a real shot at getting him here permanently.
From what I have seen in written recommendations, that should
be an easy case to make.
---jeff
-------
∂22-Jan-88 1647 Mailer Re: In defense of the British
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 16:47:09 PST
Date: Fri 22 Jan 88 16:44:48-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: Re: In defense of the British
To: JMC@Sail.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU
Message-ID: <12368748507.12.SINGH@Sierra.Stanford.EDU>
It may be that Prof. McCarthy did not read my piece
today - I'll admit it was lengthy! But then it did cover a
lot of territory.
If he would be so kind as to read it, he might find
that at least one bboard author of Indian origin (yours truly)
writing on the subject (perhaps the only one of Indian origin
who has written on it at all on su-etc) has come nowhere near
the attitude alleged by Prof. McC. wrt the Indian authors and
the British. Many of Prof. McC.'s details merely provide
illustrations for my point that oppression and brutality pre-date
the British by some centuries - the British surely didn't invent
imperialism. They were merely amongst its most recent practitioners
and, in their present weakened state, are hardly a factor for
the world's future.
Prof. McC. injects animosity where there isn't any.
It may interest him to know that the British hardly feature
at all as an excuse on the Indian political scene. That fact
might deprive him of one of his favorite straw-men to joust
with but as a consolation I'm willing to concede that the
incompetent amongst Indian politicians have a lot to learn
from the, ah, `creativity' of the White House jokers whom Prof.
McC. so admires. [Of course, one doesn't have to believe every
propagandist accusation made by Prof. McC. in his campaign.]
He might also find that in that message is a position
applicable to *all* nations, regardless of political ideology,
color of skin or racial origin. In particular it applies to
the Soviets and their satellites, and to the Soviet atrocities
in Afghanistan. And, yes, it also applies to India and Japan
and everyone else.
--->>> Why has Prof. McC. again gone off on a commie-hunt
with his dragging in of the Soviets? Just proves one of the
points I made earlier today :-)
It is also interesting to note that Prof. McC's position
translates as follows:
If a murderer commits a murder by lethal injection or a
gunshot wound as opposed to a more brutal method open to him,
such as hacking the fully conscious victim to death joint by
joint, then he should be commended for his restraint and `improvement!'
Prof. McC. would apparently like to object to calling such a
criminal a murderer on the grounds that other murderers use
much worse methods. Of course, a more appropriate image is that
of rape - Prof. McC. jumps to the defense of nations that he
perceives as humane rapists. Their relative `humane-ness' blinds
him to the fact they did in fact commit *rape*. If I read you wrong,
Sir, please to explain where your diversion into slavery fits in as
you justify, nay, almost idolize, the `progressive' British
colonialism.
--->>> Prof. McC. sets the stage, of course, for justifying
`progressive' American interventions abroad. This is precisely
the problem - look away, point to the Soviets, insinuate
on-going trouble between the Indians and the British, anything
but looking to one's own actions.
To return to Indian author(s) and the British, Sir, you
will find some explicitly stated appreciation, in my piece earlier
today, of some *domestic* political developments in England
as well as the US. That appreciation does NOT carry over *automatically*
when one attempts an evaluation of their record in their adventuring
abroad.
When will more Americans, such as Prof. McC., realize that the
commendable aspects of their *domestic* political traditions/processes
do NOT excuse their excesses abroad? The halo is non-transferable
between those two categories of action, Sir.
Wishing you a most pleasant weekend, Sir,
Yours sincerely,
Inder Singh
PS
As a private citizen I do not speak for any given Indian government
any more than Prof. McC. speaks for the Carter administration. He should
direct his queries about the position(s) of the Indian Government to
the Indian Consulate in San Francisco - I trust that they will handle
his concerns with due dispatch :-)
-------
∂22-Jan-88 1722 jlh@vsop.stanford.edu re: Jim Gray
Received: from vsop.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jan 88 17:22:04 PST
Received: by vsop.stanford.edu; Fri, 22 Jan 88 17:19:03 PST
Date: 22 Jan 1988 1719-PST (Friday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc: ULLMAN@score.stanford.edu, nilsson@score.stanford.edu
Subject: re: Jim Gray
In-Reply-To: John McCarthy <JMC@SAIL.Stanford.EDU> /
22 Jan 88 1430 PST.
When we wrote for letters on Phil Bernstein, we included Jim Gray on
the list of peers. The letters uniformily cited him as the best in the
field on database management. He is well regarded in several other
related fields. Cheriton should be in this loop also.
John
∂22-Jan-88 1806 edsel!arg@labrea.Stanford.EDU Qlisp quarterly report
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 18:06:20 PST
Received: by labrea.Stanford.EDU; Fri, 22 Jan 88 18:06:22 PST
Received: from bhopal.lucid.com by edsel id AA28440g; Fri, 22 Jan 88 16:41:54 PST
Received: by bhopal id AA03051g; Fri, 22 Jan 88 16:45:22 PST
Date: Fri, 22 Jan 88 16:45:22 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801230045.AA03051@bhopal.lucid.com>
To: rivin@Gang-of-Four.Stanford.EDU
Cc: clt@sail.Stanford.EDU, jmc@sail.Stanford.EDU
Subject: Qlisp quarterly report
Igor - Here is what Lucid did last quarter. I presume you're the right
person to send this to now?
Ron
Lucid Qlisp progress report: October 1 - December 31, 1987
Current Status
The first few weeks of the reporting period were spent bringing up the new
restructured version of Lisp designed during the previous reporting period.
This new Lisp has the dynamic-storage allocation routines and the garbage
collector properly interlocked for multiprocessor use. It also makes use
of special Alliant operating system modifications to support interrupts.
The Lisp was successfully run through the Lucid's internal test suite to
demonstrate that it was sufficiently bug-free and robust. We decided that
we will delay work on making process stacks extendable in order to focus
our work on first implementing the basic Qlisp constructs so we can
experiment with writing Qlisp programs as soon as possible. If at some
point limited stack size becomes a problem we will deal with it then.
The initial implementation of (QLET T ...) was rewritten to run under the
new version of Lisp yielding a new Qlisp. This rewrite included making
QLET more robust and also improving it to create a closure for each form
evaluated by the spawned child processes. The closure is needed to capture
any local, lexical variables referred to in the QLET.
An initial version of (QLAMBDA T ...) was implemented. Two new special
forms, QFLET and QLABELS were also implemented. These are generalizations
of the special forms FLET and LABELS in Common Lisp that can be used to
create local QLAMBDA functions. Also implemented were WAIT and NO-WAIT
constructs that can be used by the programmer to control whether the
process calling a QLAMBDA function needs to wait or not for the QLAMBDA
process to return the function's value.
A number of simple spin lock functions were added to the implementation.
These were later extended to include spin and sleep locks, and a
synchronization primitive, events. QLET and QLAMBDA were rewritten to take
advantage of these.
We looked at all the forms in Common Lisp and checked how they would
interact with Qlisp, and in particular with the control structure of Qlisp.
As expected there do not appear to be any problems.
We performed a number of experiments with Qlisp in order to test how well
the implementation worked. Based on these experiments we detected several
problems and modified the Qlisp implementation to fix them. This included
using better internal data structures and minimizing the code that was in
various critical regions.
A preliminary design for how we plan to implement CATCH and THROW in Qlisp
was done. During this it was decided to eliminate the QCATCH construct
proposed in the original Qlisp design, and to replace it with the new form
QWAIT. A number of issues regarding when it is safe to kill a process were
discussed and more work needs to be done here.
We looked into some of the issues involved in making Qlisp use deep binding
for special variables, and did the initial design work for two deep binding
schemes. The first is a very straightforward approach which should be
simple to implement and which we can make available in Qlisp in early
January. The second scheme will give us a more efficient, faster
implementation of deep binding, and we will implement it shortly after the
first.
The regular Lisp debugger has been interlocked so that Qlisp programs can
make use of it. That is only one process may be in the debugger at a time.
If a second process gets an error it will block until the debugger becomes
available.
Next Steps
As mentioned above our next steps involve implementing an initial version
of deep binding, and then improving it. Concurrently we will be
implementing CATCH and THROW so they work to kill processes, along with the
new QWAIT construct.
We will also be doing an initial design for some simple debugging and
monitoring tools to aid people developing Qlisp programs. These tools will
then be implemented.
We plan on submitting a paper on our initial results with Qlisp to several
upcoming conferences on Lisp and parallel processing.
∂22-Jan-88 1841 SINGH@Sierra.Stanford.EDU BEYOND Gandhi and the British
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 18:41:32 PST
Date: Fri 22 Jan 88 18:39:12-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: BEYOND Gandhi and the British
To: su-etc@Score.Stanford.EDU
cc: jmc@Sail.Stanford.EDU
Message-ID: <12368769332.16.SINGH@Sierra.Stanford.EDU>
After responding to Prof. McCarthy it occurred to me
that had he just seen the `Beyond' in the title to my first
message, his tangential one about Indian authors `belaboring'
the British on bboard would have been rendered quite irrelevant.
The past is important in terms of what it teaches us
so it is important not to side-step the horrors of what happened
and who did what to whom. The attempt to gloss over it is
what needs to be resisted whether it comes from Indians trying
to side-step the horrors of communal rioting or the Japanese
trying to avoid acknowledging what they did at Nanking or the
Austrians and Germans wrt the Holocaust or Prof. McCarthy wishing
to re-write Britain's colonial brutality and project it in a
`nice' light.
Any of the above groups *deserves* to be belabored if it
attempts an exercise in denial or self-justification. Other than
that I see no point in rubbing anyone's nose in the dirt - none
of the nations of our respective origins has an altogether angelic
history so we're in no position to be casting stones.
--->>> We really have no choice but to get on with the task of
shaping the future, leaving the past behind by having worked
*through* its lessons. Denial and obfuscation just ain't gonna cut
it!
Inder
-------
∂22-Jan-88 2003 edsel!arg@labrea.Stanford.EDU process overhead in QEXP
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 19:53:26 PST
Received: by labrea.Stanford.EDU; Fri, 22 Jan 88 19:53:30 PST
Received: from bhopal.lucid.com by edsel id AA29115g; Fri, 22 Jan 88 19:46:53 PST
Received: by bhopal id AA03968g; Fri, 22 Jan 88 19:50:23 PST
Date: Fri, 22 Jan 88 19:50:23 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801230350.AA03968@bhopal.lucid.com>
To: jmc@sail.Stanford.EDU
Subject: process overhead in QEXP
John - I just tried out your QEXP function with the current Qlisp and got
a process overhead of about 0.25 milliseconds. Using the old-qlisp
version I got a time closer to 1 millisecond per process, so that must
be the image you did your tests in.
Ron
∂22-Jan-88 2031 RPG Paris
Do you need a hotel for the IWoLES and ISO meetings?
If you want to stay at the same hotel as the ``US Delegation,''
send a note to Mathis@c.isi.edu or to me.
-rpg-
∂22-Jan-88 2052 JSW Eagle maintenance
To: Ball@Score.Stanford.EDU, Tom@Score.Stanford.EDU
CC: JMC@SAIL.Stanford.EDU
Tom and I today talked about the possibility of CSD-CF getting a spare Eagle
disk drive (perhaps more than one?) to serve as a replacement for any that
might break down. I think the Qlisp project would be interested in this,
since we have two machines (Ignorant and Gang-of-Four) that have Eagles
without any maintenance contract.
Could you compute how much CSD-CF would charge for such a service? Then we
can compare it with the monthly maintenance cost from Symbolics and Alliant,
and decide which is the best deal. (Symbolics wants to charge us something
like $82 per month for maintenance of an Eagle; I don't know about Alliant.)
∂22-Jan-88 2307 rivin@Gang-of-Four.Stanford.EDU Re: Qlisp quarterly report
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 23:07:04 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA07908; Fri, 22 Jan 88 23:07:21 pst
Date: Fri, 22 Jan 88 23:07:21 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801230707.AA07908@Gang-of-Four.Stanford.EDU>
To: edsel!arg@labrea.Stanford.EDU, rivin@Gang-of-Four.Stanford.EDU
Subject: Re: Qlisp quarterly report
Cc: clt@sail.Stanford.EDU, jmc@sail.Stanford.EDU
Thanks. (yes, I am the right person...)
∂23-Jan-88 0700 JMC
Future of lisp msg.msg[1,jmc]/179p
∂23-Jan-88 1026 nilsson@Tenaya.stanford.edu Jim Gray
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Jan 88 10:26:09 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA23611; Sat, 23 Jan 88 10:25:51 PST
Date: Sat, 23 Jan 88 10:25:51 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801231825.AA23611@Tenaya.stanford.edu>
To: ULLMAN@Score.stanford.edu
Cc: reges@Score.stanford.edu, jmc@Sail.stanford.edu, jlh@VSOP.stanford.edu
In-Reply-To: Jeffrey D. Ullman's message of Fri 22 Jan 88 14:07:35-PST <12368719888.45.ULLMAN@Score.Stanford.EDU>
Subject: Jim Gray
I'll leave it to Stuart to follow up on this. What would a "reasonable
salary be?" To the extent that it is higher than we pay a lecturer
for a course, can the difference be made up out of someone's research
project? -Nils
∂23-Jan-88 1031 hilbert@alan.stanford.edu re: CSLI Internships
Received: from alan.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Jan 88 10:31:50 PST
Received: by alan.stanford.edu (3.2/4.7); Sat, 23 Jan 88 10:35:59 PST
Date: Sat 23 Jan 88 10:35:58-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: re: CSLI Internships
To: JMC@SAIL.STANFORD.EDU
Message-Id: <569961358.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
They are intended for undergraduates. If you want more information I
can send you another copy of the announcement.
Dave Hilbert
-------
∂23-Jan-88 1309 edsel!jlz@labrea.Stanford.EDU Paris hotel
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 13:09:37 PST
Received: by labrea.Stanford.EDU; Sat, 23 Jan 88 13:09:45 PST
Received: from sunvalleymall.lucid.com by edsel id AA00603g; Sat, 23 Jan 88 12:43:50 PST
Received: by sunvalleymall id AA11508g; Sat, 23 Jan 88 12:47:31 PST
Date: Sat, 23 Jan 88 12:47:31 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8801232047.AA11508@sunvalleymall.lucid.com>
To: jmc@sail.stanford.edu
Cc: edsel!jlz@labrea.Stanford.EDU
Subject: Paris hotel
What days do you need the hotel in Paris? Dick will be in Paris
from 2/20 - 2/27, leaving on the 27th.
---jan---
∂23-Jan-88 1412 REGES@Score.Stanford.EDU Re: Jim Gray
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 14:12:48 PST
Date: Sat 23 Jan 88 14:07:35-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: Re: Jim Gray
To: ULLMAN@Score.Stanford.EDU
cc: nilsson@Score.Stanford.EDU, jmc@Sail.Stanford.EDU, jlh@VSOP.Stanford.EDU
In-Reply-To: <12368719888.45.ULLMAN@Score.Stanford.EDU>
Office: CS-TAC 22, 723-9798
Message-ID: <12368982030.15.REGES@Score.Stanford.EDU>
The normal reimbursement for teaching one course is $3250. Of course, if he
teaches on TV, he can earn unrestricted funds as well. Given that the material
is rather advanced, I would not be inclined to spend more, especially
considering the fact that people like Leslie Lamport and Joe Halpern teach such
courses (and on TV) for free.
I don't suppose we could get him to teach 108A (half joke/half serious). For
a class like that I would not think it was setting a bad precedent to pay more
like $5K or $6K.
-------
∂23-Jan-88 1418 nilsson@Tenaya.stanford.edu Feb 17 visit
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Jan 88 14:18:46 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA23803; Sat, 23 Jan 88 14:16:01 PST
Date: Sat, 23 Jan 88 14:16:01 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801232216.AA23803@Tenaya.stanford.edu>
To: schwartz@vax.darpa.mil, simpson@vax.darpa.mil
Cc: engelmore@sumex, jmc@sail, val@sail, genesereth@score, ginsberg@sushi,
shoham@score, latombe@coyote, binford@coyote, feigenbaum@sumex,
levinthal@sierra, stan@ai.sri.edu, buckley@score, friedland@sumex
Subject: Feb 17 visit
Jack and Bob,
We are planning what we hope is a useful agenda for you for the "AI at
Stanford" day. The KSL people will be seeing you in the morning, and
I take it that Bob Simpson will be in charge of getting you there at
the appointed hour. I will probably sit in on the KSL meetings and will
thus be there for the "baton passing" of you from KSL to the rest of
the Stanford AI activities around noon.
This note concerns primarily a suggested agenda for the afternoon.
Since time is short, the agenda does not include everything that we
might have wanted to include. It's our best guess at how you will
want to spend the time, and it has places for flexible, run-time
selections. We also can adapt it before Feb 17 to meet your needs
better if you let us have your comments. It is primarily
"subject-oriented" rather than "project-oriented" because we assume
that the the major DARPA-sponsored AI projects that the afternoon
people participate in will or have been "project-reviewed" at other
times (vision, McCarthy's commonsense reasoning project, Nilsson's ICA
project). These DARPA-sponsored projects are all carried on in the
milieu of an energetic and active subject-oriented set of AI research
activities at Stanford.
Here is our suggestion:
Lunch noon-ish - 1:30
"Combining Reasoning with Action"
An overview of the various approaches being studied. At Jack's
discretion, one of the approaches mentioned in the overview can
then be presented (by the appropriate person) in much greater
detail. --45 minutes
"Complexity Issues"
An overview of how we are approaching the problems of complexity
in AI reasoning systems. Again, there are alternatives being
explored, and one of these, at Jack's discretion, can be elaborated
by the appropriate person. --45 minutes
Demonstration of the "Helios" diagnostic reasoning system.
Mike Genesereth --20 minutes
"Autonomous Robots"
Mike Genesereth and Jean-Claude Latombe
A substantial part of the AI research of Genesereth/Latombe is now
being motivated by the goal of designing autonomous robots whose
computational capabilities span the spectrum from task-level reasoning
to real-time control. --30 minutes
"Formalizing Commonsense Knowledge and Reasoning"
John McCarthy and Vladimir Lifschitz
Rationale, latest research results, and future directions. -45 minutes
"Round Table"
How does it all fit together? How is it related to the
specific DARPA projects? Why it's important. --30 minutes
6:00 p.m. Departure
You will note that we have not assigned specific talks to the vision
research of Tom Binford. (I think that was recently
project-reviewed?) Neither do we have an agenda slot for Nilsson's
Intelligent, Communicating Agents Project. (That will be project
reviewed in April or May with demos, I believe, and involves
substantial SRI/Rockwell participation.) The ICA project needs more
than a slice of an afternoon at Stanford, I think. The Stanford part
of the ICA effort overlaps many of the research subjects we will be
presenting anyway---especially combining reasoning with acting and
nonmonotonic reasoning. We are also leaving out a possible tour of
our robotics laboratory (tours take time, we'd be glad to show you our
lab, but we are going to leave it up to you to suggest what you don't
see or hear about instead). Our new AI faculty member, Yoav Shoham,
is doing some important research on reasoning about problems involving
time and causality and is branching out into some "non-logical"
approaches. But, alas, again time presses, and we decided to let it
suffice to introduce you to Yoav at lunch. Lastly, I would very much
like Jack to see some experimental facilities that we will ultimately
be using in our Aero/Astro Department---a flat, very large, polished,
granite table on which we propose to experiment with air-cushioned,
two-armed "robots" that are jet-propelled in a two-dimensional
"gravity-free" space performing space-assembly tasks. Again, not
enough time.
Please let us know your reactions and any changes you might like
to see in all of this. I will be away during the week of
Jan 25-29, but will be able to answer net mail on my return.
Regards,
Nils
∂23-Jan-88 1438 T.TECHNO@MACBETH.STANFORD.EDU Hello...
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 14:38:53 PST
Date: Sat 23 Jan 88 14:38:10-PST
From: The Technocrat <T.TECHNO@MACBETH.STANFORD.EDU>
Subject: Hello...
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12368987599.306.T.TECHNO@MACBETH.STANFORD.EDU>
I'm Frank Barrus, and you don't know me, but I was wondering
if I would be able to have an online interview with you
in the next couple of months.... probably in March or April?
-------
∂23-Jan-88 1643 SHOHAM@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 16:43:39 PST
Date: Sat 23 Jan 88 16:39:20-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 22 Jan 88 15:24:00-PST
Message-ID: <12369009656.10.SHOHAM@Score.Stanford.EDU>
No - I was wondering about that myself.
-------
∂24-Jan-88 0834 T.TECHNO@MACBETH.STANFORD.EDU re: Hello...
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 08:34:36 PST
Date: Sun 24 Jan 88 08:33:59-PST
From: The Technocrat <T.TECHNO@MACBETH.STANFORD.EDU>
Subject: re: Hello...
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sat 23 Jan 88 18:36:00-PST
Message-ID: <12369183444.289.T.TECHNO@MACBETH.STANFORD.EDU>
Okay, thanks for the reply. It'll be a couple of months,
but I've got a major project coming up dealing with the early days
of hacking at MIT, AI, etc., and with you being one of the pioneers in
the field, it would be great to interview you.... I'll let you know when
things become more finalized.
-------
∂24-Jan-88 1234 MATHIS@A.ISI.EDU Paris reservations
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 12:34:28 PST
Date: 24 Jan 1988 15:33-EST
Sender: MATHIS@A.ISI.EDU
Subject: Paris reservations
From: MATHIS@A.ISI.EDU
To: Bobrow.pa@XEROX.COM
To: willc%tekchips.tek.com@RELAY.CS.NET
To: Dussud%AUSOME%TI-CSL@RELAY.CS.NET
To: rpg@SAIL.STANFORD.EDU, gregor.pa@XEROX.COM
To: Baggins@IBM.COM, Masinter.pa@XEROX.COM
To: Mathis@A.ISI.EDU, KMP@SCRC-STONY-BROOK.ARPA
To: Scherlis@VAX.DARPA.MIL, gls@THINK.COM
To: jmc@SAIL.STANFORD.EDU, edsel!jlz@LABREA.STANFORD.EDU
Message-ID: <[A.ISI.EDU]24-Jan-88 15:33:20.MATHIS>
Here is the reply Telex confirming our reservations:
Date: Sun Jan 24, 1988 9:25 am EST
From: MCI Mail
TO: * Robert F Mathis / MCI ID: 347-4307
Subject: Telex Message
OTENAPO 640609FHERE IS THE HOTEL NAPOLEON
WE CONFIRM THE RESERVATION OF 9 SINGLE ROOMS AT 890 FF,BREAKAFAST
NOT INCLUDED 45 FF PER PERSON, ARRIVING FEBRUARY 21, DEPARTING
FEBRUARY 27, AT THE FOLLOWING NAMES:
DANNY BOBROW
WILL CLINGER
PATRICK DUSSUD
RICHARD GABRIEL
GREGOR KICZALES
LARRY MASINTER
ROBERT MATHIS (DEPARTING FEB 26)
JOHN MCCARTHY
GUY L.STEELE
REGARDS
OTENAPO 640609F
If there are any changes, please let me know and I will forward them.
Hotel Napoleon, 40 av. Friedland
(French phone number 47.66.02.02, Telex 640609)
Thom Linden and Kent Pitman -- are you going?
Bob Mathis
∂24-Jan-88 1401 Mailer 1. Self-defense [Was Re: In defense of the British]
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 14:01:31 PST
Date: Sun 24 Jan 88 13:59:09-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: 1. Self-defense [Was Re: In defense of the British]
To: JMC@Sail.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 24 Jan 88 12:01:00-PST
Message-ID: <12369242641.12.SINGH@Sierra.Stanford.EDU>
Here's a followup to a few of Prof. McCarthy's
clarifications:
1. He says:
`` ...In grumbling about Indians, I was more influenced by
what I have read than about specific BBOARD contributions... ''
So now we've moved away from what appeared specifically
on this bboard, perhaps bboards in general (I don't know which
other bboards Prof. McC. reads.) We have no way of knowing which
of your sources give you this impression, Prof. McCarthy, so I,
for one, am not going to waste any energy answering for un-specified
sources that have influenced your thinking. There are about a billion
Indians now on the planet - who knows which of them you've been
relying on for your information.
Prof. McCarthy goes on to say:
``...although what I have read from Indians on BBOARDs doesn't
seem to require revising my opinion.''
If the Professor is referring to recent postings (last
year or two) I find myself to be the only author of Indian origin
who has written on the subject. Maybe I've missed (at most) one
or two others who may have written on the subject a long time ago
but I sure don't remember - I'll be happy to be corrected, Professor,
if *your* memory has more accurate factual recall on the matter.
--->>> So let's look at *my* record on the matter of the British:
``... The British were merely the latest in a long list of
oppressors the world has seen. And, despite the impression
left by the last 200 and odd years, a nation did not need to
be white in order to perpetrate atrocities wherever it could
get away with it - India itself has a blemished history of
prejudice and oppression of its own people and its neighbors
long before `white' men emerged from the caves, so to speak.
In this century one need only look at pre-WWII Japan's actions
in Korea and China to drive home this point (remember Nanking
in 1937/38?)
''
The above does seem to require a revision of your opinion
Prof. McCarthy unless, of course, you *choose* to be blind to what's
actually on record. England is only one of many nations mentioned
above and its mention there hardly constitutes `dwelling on past
imperialism.' Since the British were the subject of discussion
*before* I made any comments on the matter, I devoted a grand total
of two sentences to them subsequently, still _only in passing_ as
far as my main thrust was concerned. I stand by that sentence and
invite you to refute it with facts:
``
... I'm no apologist for the British. They did ghastly
things in India and were bloody bastards for the most part.
I'm glad the Empire has been dismantled, Churchill's distress
notwithstanding.
--->>> The lessons of history need, however, to be placed in
a larger context than just the last couple hundred years. I
submit to you that British common law and their system of domestic
governance, and its successor, the American system of justice
and government, are both at the leading edge of evolution in
the conduct of human affairs.... ''
Even in the above please notice the paragraph with the
emphasis, Professor. It expresses ADMIRATION for the British
and gives due credit where credit is in order. That paragraph
sets up the British and American innovations in self-governance
as models worthy of *emulation* by the rest of the world! How
did you manage to miss that, coming from an Indian author? Just
a tad at variance with *your* characterization of Indian authors,
isn't it??
To complete the process of drawing your attention to the
record, please note the following from me (an Indian author on bboard):
``... So where does all of this leave us?
It calls for all nations to examine their actions and
*acknowledge* the errors that may have been committed. No nation's
populace should be exempt from this - India, Japan, China, Great
Britain, Germany, the US, all. This is important in order that
the mistakes not be repeated - colonialism, casteism, racism,
the Holocaust, Nanking, Vietnam. So long as an immature national
`pride' prevents such self-examination we run the risk of a repetition....''
Sure doesn't seem to single out the British at all! Where
*did* you get that impression, Professor? You've clearly not read
the above and perhaps not read the likes of Naipaul, Akbar, Chaudhuri
and Mehta, all of whom are highly accessible Indian authors writing
in English. (More likely, you've perhaps read bits and parts of
their works with the same degree of inattention and selective
perception that you've applied to the bboard pieces you objected
to above.)
So much for self-defense :-)
In a companion piece I'm going to ask you a question or
two about *your* position, Professor. As always, you're at liberty
to respond or not, as you like.
Cheers,
Inder
PS
If you're looking for substantive negative things to say
about things and people Indian, you're welcome to ask me another
time. There *is* such a list, Professor, but you ain't got even
the beginnings of it in what you've come up with so far. I'm sorry
to disappoint you but the evils in Indian society have very little
to do with the British who may just have exacerbated some of them
while mitigating others.
-------
∂24-Jan-88 1618 L.LILITH@OTHELLO.STANFORD.EDU re: The British and the subhumans
Received: from OTHELLO.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 16:18:14 PST
Date: Sun 24 Jan 88 16:17:26-PST
From: Pilar Ossorio <L.LILITH@OTHELLO.STANFORD.EDU>
Subject: re: The British and the subhumans
To: JMC@SAIL.STANFORD.EDU
cc: L.LILITH@OTHELLO.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 22 Jan 88 17:20:00-PST
Message-ID: <12369267813.210.L.LILITH@OTHELLO.STANFORD.EDU>
WRT colonists' treatment of natives v. govornment treatment of
natives, I don't know about the Spanish gov but I do know that most
massacres of American Indians were carried out by US gov. troops. The
book _Bury My Heart at Wounded Knee_, which I think should be required
reading each year at Thanksgiving, gives a chapter or two of the
history of many large tribes of American Indians. Information
provided by this book would indicate that the US gov made treaties
that it never intended to carry out, or that it felt perfectly
comfortable abrogating whenever the mood in Washington changed; when
gold or oil was discovered on reservation land for instance. Yes,
there were clashes between settlers and American Indians, there were
also cases where the two groups got on quite well, but as far as I can
tell, the US gov has *rarely* done anything to protect the rights of
American Indians. The breaking of treaties and the illegal and/or
forced removal of Indians from their land continues to this day. In
the south west US two tribes (sorry, I don't remember which right
now), are fighting to remain on their land; their mineral rich land.
-------
∂24-Jan-88 1647 L.LILITH@OTHELLO.STANFORD.EDU Re: In defense of the British
Received: from OTHELLO.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 16:47:35 PST
Date: Sun 24 Jan 88 16:45:48-PST
From: Pilar Ossorio <L.LILITH@OTHELLO.STANFORD.EDU>
Subject: Re: In defense of the British
To: JMC@SAIL.STANFORD.EDU
cc: L.LILITH@OTHELLO.STANFORD.EDU, su-etc@OTHELLO.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 24 Jan 88 12:01:00-PST
Message-ID: <12369272977.210.L.LILITH@OTHELLO.STANFORD.EDU>
With regard to JMC's breakdown of the evolution of imperialist
countries' attitudes towards occupied countries/peoples, I think there
are further steps of evolution which need to be taken. In his message
he implies that the "more developed" culture knows what's "best" for
the "less developed" culture, but with graciousness the "more
developed" culture may choose not to force another country or people
into doing something even for their own good. (O.K., I know that was
an awkward and convoluted sentence, it just came out that way.)
I would like to suggest that a further step in the evolution of human
relations is the recognition that one person or group of people
rarely, if ever, has the wisdom to know what is best for others. Even
if you or your group have solved a problem that others are still
trying to solve, what worked for you might not work for them. It is
one thing to present your ideas as suggestions, and another thing to
present them as the wisdom of the more advanced to the less advanced.
There is generally more than one way to solve a problem, and if we
weren't so intent on controlling other people, we might find that the
creativity and intelligence of other human beings would lead to
"progress" that we never dreamed possible.
-------
∂24-Jan-88 1706 Mailer Thanks to Prof. McCarthy [Was Re: self defense and apology]
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 17:06:33 PST
Date: Sun 24 Jan 88 17:04:14-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: Thanks to Prof. McCarthy [Was Re: self defense and apology]
To: JMC@Sail.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 24 Jan 88 16:09:00-PST
Message-ID: <12369276333.17.SINGH@Sierra.Stanford.EDU>
That was a very gracious gesture, Sir, and I
genuinely appreciate it.
To answer your last comment briefly, may I state
that I believe the past to have only a certain non-zero,
but definitely non-zero, value in guiding our future
actions. I would agree whole-heartedly that it cannot be
our sole focus and surely shouldn't be an obsessive concern.
The past starts to loom disproportionately large when there
is an attempt either to ignore it completely or to re-write
it for political expediency.
As for modern-day imperialism, please count me in
for an un-inhibited condemnation of any nation that tries
to inflict its will on another, regardless of ideological
leanings. In particular, I'd like to see the Soviet bloc
get off the backs of their satellites, and free their own
people too. I'd like to see a lot of monarchies and theocracies
and dictatorships come down around the world but primarily from
long-term internal pressures for reform.
I hope I've addressed the question you raised for me.
Best regards,
Inder
-------
∂25-Jan-88 0700 JMC
squires
∂25-Jan-88 0700 JMC
prepare for 11
∂25-Jan-88 0759 ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu surprise present
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Jan 88 07:59:08 PST
Received: by lindy.stanford.edu; Mon, 25 Jan 88 07:59:59 PST
Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 07:58:34 PST
P1-Message-Id: US**EDU;UWAVM.ACS.WASHINGTON.EDU:LDJPJjo7
Date: Sat, 23 Jan 88 23:33-0800
X400-Trace: US**EDU; arrival Sat, 23 Jan 88 23:33-0800 action Relayed
X400-Trace: US**EDU; arrival Mon, 25 Jan 88 07:53-0800 action Relayed
From: Alice terMeulen<ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu>
Subject: surprise present
To: <JMC@sail.stanford.edu>
Message-Id: <UWAVM.ACS.WASHINGTON.EDU:LDJPJjo7*>
Hi John,
There arrived in the mail a most wondrous book from historic times
written by an American reporting on his joyous journeys in the
Netherlands.
As the only trace I could find of its origin was the CS dept at
Stanford, and Carolyn claims to be innocent, I came to hypothesize
that this was a present from you. Am I right???
If so, THANKS SO VERY MUCH!!
And are you reading Italo Calvino?
Alice
∂25-Jan-88 1039 yao.pa@Xerox.COM Industrial Lectureship
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Jan 88 10:39:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 JAN 88 10:34:20 PST
Date: Mon, 25 Jan 88 10:28:30 PST
From: yao.pa@Xerox.COM
Subject: Industrial Lectureship
To: JMC@sail.stanford.edu
Cc: Yao.pa@Xerox.COM, DEK@sail.stanford.edu
Message-ID: <880125-103420-2128@Xerox>
Dear John,
Zohar mentioned to me recently that Stanford is looking for industrial lecturers
for the coming academic year. If there are still slots available in this
program, I would be very interested in offering a seminar on "Topics in
Computational Geometry" or a related subject in AA. Please let me know if this
is a possibility.
Frances
∂25-Jan-88 1127 yao.pa@Xerox.COM Re: Industrial Lectureship
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Jan 88 11:27:36 PST
Received: from Salvador.ms by ArpaGateway.ms ; 25 JAN 88 11:24:40 PST
Date: Mon, 25 Jan 88 11:24:09 PST
From: yao.pa@Xerox.COM
Subject: Re: Industrial Lectureship
In-reply-to: "Your message of 25 Jan 88 10:44 PST"
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Cc: yao.pa@Xerox.COM
Message-ID: <880125-112440-2239@Xerox>
Thanks for the reply. I do not have serious constraints as to when this course
is to be given, although the fall quarter will work out best for me.
Frances
∂25-Jan-88 1138 JUSTESON@Sushi.Stanford.EDU letter for IBM Watson - Speech Recognition - Feb. 5 interview
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 11:38:51 PST
Date: Mon 25 Jan 88 11:34:16-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: letter for IBM Watson - Speech Recognition - Feb. 5 interview
To: jmc@Sail.Stanford.EDU
Message-ID: <12369478410.51.JUSTESON@Sushi.Stanford.EDU>
Hi, John. I'm going to go out to the Watson Center in New York to interview
with their Continuous Speech Recognition project, February 5. If you can
write a letter for me, they'll want it by the time I arrive. I know I have
at least four letters going to them, so don't feel obliged, but I assume it
would be a help. Anyway, the address is:
Peggy Lyons
Room 88-D05
P.O. Box 218
Yorktown Heights, New York 10598
(914)-945-2199 plyons@ibm.com
Thanks....
John
-------
∂25-Jan-88 1201 CRISPIN@SUMEX-AIM.Stanford.EDU Tibet
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 12:01:29 PST
Date: Mon, 25 Jan 88 11:53:56 PST
From: Mark Crispin <Crispin@SUMEX-AIM.Stanford.EDU>
Subject: Tibet
To: JMC@SAIL.Stanford.EDU
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12369481990.67.CRISPIN@SUMEX-AIM.Stanford.EDU>
JMC, if you support Tibetian independence based on the claim that the
native Tibetians want to be free of the Chinese (not necessarily verified),
then I suppose you support the independence of Hawaii and the ejection of
all non-natives from Hawaii. The only clearly-stated native vote, that
of Niihau district (100% native Hawaiian) cast the only NO vote against
statehood in 1959. Admittedly, the pro-independence people in Hawaii are
a handful (a couple of thousand at most), but there aren't all that many
native Hawaiians either.
Or, let's consider a stronger claim; that of the Seneca nation located
in territory the United States claims as part of New York State. The
Senecas have repeatedly asserted, as part of their national constitution,
that they are an independent nation. Recently, they have been issuing
passports for their nationals, which have been accepted by several
Central and South American nations. Even the US courts have been forced
to conceed that US Federal jurisdiction (e.g. the FBI) ends at the border
of the Seneca "reservations".
I expect that JMC supports the idea that the US and Canada should
formally cede the Seneca lands to the Seneca people and recognize the
Seneca nation as an independent nation. The Senecas have a stronger
claim that the Tibetians; the Tibetians *voluntarily* merged with the
Chinese hundreds of years ago. The Senecas were defeated in battle
less than two hundred years ago, and forced to sign a treaty establishing
the "reservations". The Senecas *never* acknowledged themselves as being
part of the US, even in the treaties.
Or does JMC only support non-US independence movements? Or only
independence movements against Communist nations? What does he feel
about the Basque independence movement, which in recent years has
been greatly Communist-influenced?
-------
∂25-Jan-88 1222 rivin@Gang-of-Four.Stanford.EDU I am here
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 12:22:24 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02706; Mon, 25 Jan 88 12:22:42 pst
Date: Mon, 25 Jan 88 12:22:42 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801252022.AA02706@Gang-of-Four.Stanford.EDU>
To: JMC@SAIL.Stanford.EDU
In-Reply-To: John McCarthy's message of 25 Jan 88 0218 PST <8801251019.AA01922@Gang-of-Four.Stanford.EDU>
Subject: I am here
I have actually been back since friday night (sorry I didn't send
email...) Should I send off the thing to Squires? Judging by the end
of flames from Lucid, it is fine with them, and judging by the total
lack of response from les, we will not hear from him... I assume
Squires@vax.darpa.mil is the correct mailing address.
∂25-Jan-88 1224 simpson@vax.darpa.mil AI and Formal Reasoning Proposal
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 25 Jan 88 12:23:34 PST
Received: from sun35.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA11980; Mon, 25 Jan 88 14:33:28 EST
Posted-Date: Mon 25 Jan 88 14:28:54-EST
Received: by sun35.darpa.mil (5.54/5.51)
id AA05729; Mon, 25 Jan 88 14:28:56 EST
Date: Mon 25 Jan 88 14:28:54-EST
From: Bob Simpson <SIMPSON@vax.darpa.mil>
Subject: AI and Formal Reasoning Proposal
To: JMC@sail.stanford.edu
Message-Id: <570137334.0.SIMPSON@VAX.DARPA.MIL>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
John: In your proposal to me, you request permission to purchase some computer
equipment (two sun workstations). Because of that I need more paperwork from
you in order to satisfy the the ADP purchase request. I need:
1. A letter on institution letterhead signed by a senior official
stating that Stanford either cannot or will not provide the ADPE from your own
resources.
2. Sole source justification or explanation of the method of competitive
acquisition, as appropriate, for each piece of ADPE.
3. Lease/Purchase analysis clearly showing the reason for the lease or
purchase decision.
4. Cost for each piece of ADPE.
Sorry about this, but I didn't notice the addition of this equipment when you
updated the budget. Please send this along as soon as possible, since the
approval package is being held awaiting its arrival. -- Bob
-------
∂25-Jan-88 1503 Qlisp-mailer Next meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 15:03:33 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03152; Mon, 25 Jan 88 15:03:50 pst
Date: Mon, 25 Jan 88 15:03:50 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801252303.AA03152@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Next meeting
Will be this wednesday (the 27th) at noon in MJH352. The major topic will be
the next eighteen months of QLISP.
CUthere
∂25-Jan-88 1657 ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu RE: re: surprise present
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:57:39 PST
Received: by lindy.stanford.edu; Mon, 25 Jan 88 16:58:20 PST
Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 16:56:46 PST
P1-Message-Id: US**EDU;UWAVM.ACS.WASHINGTON.EDU:LDLIYWVl
Date: Mon, 25 Jan 88 16:56-0800
X400-Trace: US**EDU; arrival Mon, 25 Jan 88 16:56-0800 action Relayed
X400-Trace: US**EDU; arrival Mon, 25 Jan 88 16:56-0800 action Relayed
From: Alice terMeulen<ATM%UWACDC.ACS.WASHINGTON.EDU@forsythe.stanford.edu>
Subject: RE: re: surprise present
To: <JMC@sail.stanford.edu>
Message-Id: <UWAVM.ACS.WASHINGTON.EDU:LDLIYWVl*>
Now I am infinitely curious where you found that Griffis antiquity? Not in
the desert down there, is it? It is a great present - I have started reading
it as bedtime reading, but can't put it down!
And have you read Calvino's "Uses of Literature"? Lectures he gave at Harvard
some time ago.
If you don't have it, I'll non-surprise you with it.
So long,
Alice
∂25-Jan-88 2226 helen@psych.Stanford.EDU Re: starting earlier
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 22:26:36 PST
Received: by psych.Stanford.EDU (3.2/4.7); Mon, 25 Jan 88 22:26:01 PST
Date: Mon, 25 Jan 88 22:26:01 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: starting earlier
Cc: helen@psych.Stanford.EDU
Yes, that sounds just perfect. Turns out I have another subject
to "run" and he is arriving at 1 p.m. So 11:30 or even earlier is
fine. Just let me know. See you then!
-helen
∂26-Jan-88 0700 JMC
squires 694-5800, 856-4213
∂26-Jan-88 1113 BSCOTT@Score.Stanford.EDU Letter to Col. Simpson
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:13:36 PST
Date: Tue 26 Jan 88 11:03:21-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Letter to Col. Simpson
To: JMC@Sail.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12369734924.18.BSCOTT@Score.Stanford.EDU>
The letter containing the information needed by Col. Simpson is going out
to him today via Federal Express. I have just confirmed this with Sponsored
Projects.
Betty
-------
∂26-Jan-88 1240 Mailer failed mail returned
The following message was undeliverable to the address(es) below
because the destination Host Name(s) are Unknown:
jas@uk.ac.lancs.comp
------- Begin undelivered message: -------
26-Jan-88 1239 JMC passing the buck
To: jas@uk.ac.lancs.comp
I am no longer in charge of workshops, so I'm forwarding your note of dec 28
to Peter Hart who is.
------- End undelivered message -------
∂26-Jan-88 1303 rivin@Gang-of-Four.Stanford.EDU [edsel!jlz@labrea.Stanford.EDU: Next meeting]
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 13:03:19 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00225; Tue, 26 Jan 88 13:04:43 pst
Date: Tue, 26 Jan 88 13:04:43 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801262104.AA00225@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: [edsel!jlz@labrea.Stanford.EDU: Next meeting]
I guess this means that any serious discussion will have to be
postponed till next wednesday (so presumably your time may be better
spent at that theory faculty meeting...)
Return-Path: <edsel!jlz@labrea.Stanford.EDU>
Date: Tue, 26 Jan 88 10:50:32 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
To: rivin@gang-of-four.stanford.edu
Cc: edsel!arg@labrea.Stanford.EDU, edsel!jlz@labrea.Stanford.EDU
In-Reply-To: Igor Rivin's message of Mon, 25 Jan 88 15:03:50 pst <8801252303.AA03152@Gang-of-Four.Stanford.EDU>
Subject: Next meeting
Dick is out of town til Thursday.
---jan---
∂26-Jan-88 1309 JSW Symbolics Multiprocessor
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
LES@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU,
JDP@SAIL.Stanford.EDU, AIR@SAIL.Stanford.EDU,
RPG@SAIL.Stanford.EDU
Carl White from Symbolics would like to give us a presentation of their
new multiprocessor (based on the Ivory chip). I tentatively arranged the
time of 2:30 this Thursday, but this turns out to be bad for some people.
So if you're interested, please tell me what are good or bad times for you
(within the next week) and I'll reschedule the visit.
∂26-Jan-88 1320 JSW
∂26-Jan-88 1310 JMC re: Symbolics Multiprocessor
[In reply to message rcvd 26-Jan-88 13:09-PT.]
I'm interested in the Symbolics multi-processor.
JJW - What is the best time for the meeting, for you?
∂26-Jan-88 1459 APPELT@WARBUCKS.AI.SRI.COM Backing up LISPMs
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 26 Jan 88 14:59:07 PST
Date: Tue 26 Jan 88 14:57:39-PST
From: Doug Appelt <APPELT@SRI-WARBUCKS.ARPA>
Subject: Backing up LISPMs
To: jsw@SAIL.STANFORD.EDU, nilsson@SCORE.STANFORD.EDU,
genesereth@SCORE.STANFORD.EDU, jmc@SAIL.STANFORD.EDU
Folks,
When I came to Stanford, I was shocked and amazed to find that there
was no provision for automatic backup of files on lisp machines.
This situation has raised my anxiety level somewhat, and so therefore I
have taken it upon myself to import from SRI our system for automatic
LISPM file backup.
Here's how it all works. The machine EGREGIOUS is designated our
official backup server. Its local LMFS contains nothing but temporary
backups. Every night around midnight, it goes around to all the
lisp machines in the backup coop and asks them if they have any local files
that have not been archived. If any are found it sucks them over the network
to its own local file system and holds them there until the local
LMFS fills up, or until somebody comes along and actually dumps them
out onto a tape. After the files are safely backed up, it reaches across
the net and asks the owner machine to twiddle its backup bit, then
deletes the file from EGREGIOUS.
The actual backing up will be done on Polya. All that is necessary
for this wonderful magic to happen is for people who have machines to be
backed up to agree to cough up some small quantity of money to pay for
some reels of tape and time on Polya required to do the dumping.
Probably the ICA project should get a break, since our machine is volunteering
to be the backup server.
I hereby solicit comments, suggestions, etc. Do you
want to join the coop? Do you want archival backup, or should
the dumps be recycled periodically? What period?
Note that this method of backup is superior to any ad-hoc
backup because all the LISPM file properties are properly preserved
just as they would be if you ran the dump yourself.
- Doug
-------
∂26-Jan-88 1533 SLOAN@Score.Stanford.EDU Visiting Research Associates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 15:33:16 PST
Date: Tue 26 Jan 88 15:28:48-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Visiting Research Associates
To: McCarthy@Sail.Stanford.EDU, Les@Sail.Stanford.EDU,
Pratt@Navajo.Stanford.EDU
Message-ID: <12369783249.39.SLOAN@Score.Stanford.EDU>
Have you had a chance to look over the resumes that I put into your box??
Do you have any thoughts about whether or not Ian Foster and Steven Gregory
will be invited to spend spring quarter here will Dr. Clark is here? Please
let me know if you've made a decision. I'd like to let Dr. Clark know soon.
Thank you.
--Yvette
-------
∂26-Jan-88 1603 JSW Disk maintenance
To: IGS@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
JMC@SAIL.Stanford.EDU
We need to do one of the following things:
(1) Pay Symbolics about $200 for a service call in late December; Ramin
called because he couldn't boot the machine, and the problem was that the
attached Eagle disk (which isn't on our service contract) had been shut
off because of the university power shutdown.
(2) Buy Symbolics maintenance for this disk, at about $90 per month. This
will cover us if the disk breaks down, and they will not charge us for the
December service call if we do so.
(3) Get CSD-CF to buy a spare Eagle as "insurance" against a breakdown of
any of the ones owned by various groups. I've asked Jim Ball and Tom
Dienstbier to estimate the cost of this since we could use this kind of
coverage on Gang-of-Four as well.
If we decide not to buy Symbolics maintenance, they would like us to
create an open purchase order for the disk, in case any future problems
turn out to require them to work on it. And we will also need to get a
purchase order for the December work.
On the subject of disks, I think we should plan for the Qlisp project
to buy another Eagle in the near future for Gang-of-Four. We can live
for a while on the current amount of space, but it requires constant
effort to remove less useful files that are taking up space. I think
the price of an Eagle is now $5000 to $6000.
∂26-Jan-88 1710 CS.PURVIS@R20.UTEXAS.EDU Hello
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 17:10:01 PST
Date: Tue, 26 Jan 1988 19:11 CST
From: CS.PURVIS@R20.UTEXAS.EDU
To: jmc@sail.stanford.edu
Subject: Hello
I hope things are well with you "back home" in Stanford. I'm sure
everyone conveyed to you how much your presence here in Texas was
appreciated.
It occurs to me that I gave you a key to room 4.134 in Taylor Hall.
If you should happen to still have that key and could mail it back to
me, it would be helpful. (We have to swear, in front of a picture of
John Wayne, that we won't lose any keys when they're given to us.)
Many thanks,
Martin Purvis
∂26-Jan-88 1723 JSW Symbolics multiprocessor presentation
To: "@QLISP1.DIS[1,JSW]"@SAIL.Stanford.EDU
Carl White from Symbolics will be here at 2:30 next Monday, February 1,
to talk about their multiprocessor Lisp machine. I'll send out another
message when I find out what room we can use.
The machine has apparently not been officially announced yet, so he
has asked that people representing their competitors (e.g., TI) not
attend this meeting.
∂26-Jan-88 1800 JMC
food for Wednesday dinner
∂26-Jan-88 1807 CS.PURVIS@R20.UTEXAS.EDU Hello
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 18:07:22 PST
Date: Tue, 26 Jan 1988 20:05 CST
From: CS.PURVIS@R20.UTEXAS.EDU
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Hello
In-reply-to: Msg of 26 Jan 1988 19:45-CST from John McCarthy <JMC at SAIL.Stanford.EDU>
O.K., thanks, I'll check with Suezette.
--Martin
∂26-Jan-88 2030 Qlisp-mailer new-qlisp image
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 20:30:15 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01313; Tue, 26 Jan 88 20:30:31 pst
Received: by labrea.Stanford.EDU; Tue, 26 Jan 88 20:30:22 PST
Received: from bhopal.lucid.com by edsel id AA16632g; Tue, 26 Jan 88 20:20:35 PST
Received: by bhopal id AA24055g; Tue, 26 Jan 88 20:24:18 PST
Date: Tue, 26 Jan 88 20:24:18 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801270424.AA24055@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp image
There is a new version of new-qlisp on /lucid/bin that fixes the problem
with bignums that Arkady encountered.
Ron
∂27-Jan-88 0902 RICHARDSON@Score.Stanford.EDU Meeting at Robotics Lab for 2/3/88
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:02:43 PST
Date: Wed 27 Jan 88 08:57:54-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Meeting at Robotics Lab for 2/3/88
To: latombe@Whitney.Stanford.EDU, Binford@Whitney.Stanford.EDU,
Jmc@Sail.Stanford.EDU, genesereth@SUMEX-AIM.Stanford.EDU,
shoham@Score.Stanford.EDU, feigenbaum@SUMEX-AIM.Stanford.EDU,
buchanan@SUMEX-AIM.Stanford.EDU, ok@Coyote.Stanford.EDU
Message-ID: <12369974232.10.RICHARDSON@Score.Stanford.EDU>
You are invited to attend a presentation to the Visiting Committee at the
Robotics Lab in Cedar Hall on Wednesday, February 3 at 8:15. A continental
breakfast will be served. Please respond to Heidi - richardson@score.
-------
∂27-Jan-88 0909 MPS meeting
Chris Robertson called (202-334-2605) regarding the
committee meeting to study international development in
computer science and technology. The meeting will take
place on March 25th and 25th in Washington, DC
Pat
∂27-Jan-88 0930 AI.PETRIE@MCC.COM Your Institution
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:30:13 PST
Date: Wed 27 Jan 88 11:29:47-CST
From: Charles Petrie <AI.PETRIE@MCC.COM>
Subject: Your Institution
To: jmc@SAIL.STANFORD.EDU
Reply-To: Petrie@MCC.com
Message-ID: <12369980034.12.AI.PETRIE@MCC.COM>
Bob Boyer related to me that you had the idea of something like an institute
where you and a few others would gather for years to work on common
sense and other problems without interruption. And you wanted to
test the feasibility of such an idea for a year or so. Our funding
entity, ACA, here at MCC would at the least entertain supporting such
a test.
We could certainly provide office space (and computers if any were needed.)
Do you have any idea of the funds required to support such an enterprise?
We might even be able to get some assistance from UT. Would you be
willing to be available some number of hours during the year for general
consulting? That would help justify our support to the shareholders.
Please let me know if you have any interest in exploring this option.
Regards,
Charles
-------
∂27-Jan-88 1159 Mailer failed mail returned
In processing the following command:
MAIL
The following message was unsent because of a syntax error:
------- Begin undelivered message: -------
27-Jan-88 1159 JMC re: Ullman proposal considered harmful
To: ULLMAN@SCORE.Stanford.EDU, faculty@SCORE.Stanford.EDU,
ARK@SAIL.Stanford.EDU
[In reply to message from ULLMAN@Score.Stanford.EDU sent Wed 27 Jan 88 09:10:08-PST.]
Since about 1958 I have believed that one should keep ones entire
records in computer files permanently. At that time disks didn't exist,
so the idea was not realizable. Since about 1970 it has been realizable
and I have done it. The cost at first was high, but I reasoned that
technology would bring costs down. Indeed the cost of the necessary
disk files has come down. However, considerations of bureaucratic
convenience, like those advanced by Jeff Ullman in his recent message
have kept the price of disk storage up and even increased it. The ratio
of the price charged by CSD to the cost of disk files has steadily
increased. I am now paying several thousand dollars a month for my
files, and now Jeff proposes to drive me off CSD machines completely
by basing charges entirely on disk usage.
Like many proposals that suppose people will behave as before when
pricing is changed this one will probably fail even if Jeff gets his
way. In the first place, I'll finally accept the inconvenience of
moving to a personal computer. The inconvenience is that I won't
have institutionalized backup, I won't have the same files at home
and in the office and I'll have to adapt to a smaller character set
than I have been able to use since 1966. Other people will also strive to
reduce their files and to get certain files declared part of the
institutional overhead. The 3.2 gigabytes on Polya will simply go unused,
because people will waste their time figuring out how to economize on file
use in face of a charging algorithm unrelated to the cost of providing the
service.
In spite of substantial reductions in the cost of computation, CSD-CF is
facing a financial crisis. This is because people are going to personal
computers for financial reasons. CSD-CFs costs are in a large measure
personnel. People who buy personal computers consider that they don't
need the services CSD-CF provides that use personnel. I don't know
whether this is true or not. I don't even know whether the truth
of the matter can be ascertained. CSD-CF's costs are known, and their
allocation among personnel, equipment and external services can be
calculated.
However, the personal computers and other computers belonging to research
projects have the following hidden costs.
1. They sometimes get help from CSD-CF that is not charged for.
CSD-CF doesn't charge for mere expertise when the expert doesn't have to
do much direct work, but it costs plenty to have an expert on hand. It
might be hard to charge for work that is mainly advice. It could only be
done by a tax on computers, and this would be resisted.
2. Graduate students and faculty spend time maintaining the
machines and their software that is charged to research and detracts
from real research.
3. Some of the research projects have substantial hacking
components.
I don't know whether CSD-CF can survive in the long run, especially as
some of the faculty regard its computers as dinosaurs and are willing
to accept the previously mentioned costs in order to avoid using it.
If CSD-CF is to survive, it will have to charge fully for every service it
provides, and it will probably have to reduce its personnel costs. I have
no complaint about how Jim Ball does his job, but I think CSD-CF may not
be able to afford a full time manager in the long run.
------- End undelivered message -------
∂27-Jan-88 1322 AIR QLISP & GCD
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
IGS@SAIL.Stanford.EDU, JDP@SAIL.Stanford.EDU,
JJW@SAIL.Stanford.EDU
Here are some new results of my experimenting with polynomials. By
suggestion of Igor (oral one) and D. Knuth (the art of programming,
vol. 2 p 270) I used modular arithmetic to implement polynomial GCDs
(for the polynomials in one variable). The algorithm is pretty
straightforward: the gcd is calculated using arithmetic modulo some
prime, thus avoiding dealing with fractions with large numerators and
denominators; actually, since Zp is a field we can avoid fractions
altogether. GCDs are calculated modulo several primes and the GCD in
Z is calculated using Chinese Remainder theorem.
The Euclid algorithm normally generates GCD with rational
coefficients, and therefore straightforward application of the Chinese
Remainder theorem would not help us to restore desired GCD. Although
the Gauss Lemma asserts that there exists a conjugate of GCD with
integral coefficients, it is not obvious how to recover it from the
representations of GCD modulo some prime.
There exists a known solution for this problem. In order to do this
consider the result of multiplication of the GCD generated by the
Euclid algorithm by a such number that the leading coefficient would
become a GCD of the leading coefficients of the original polynomials.
Since the leading coefficient of the desired GCD with integral
coefficients must divide the GCD of the leading coefficients of the
original polynomials, the polynomial obtained in such a way will be
the result of multiplication of the desired GCD (with the integral
coefficients) by some integer. This integer does not depend on the
prime selected. Therefore we can use the Chinese Remainder theorem to
recover this polynomial. When we divide polynomial by its content
thereafter we will have desired GCD.
The second problem is a technical problem of effective division in
modular arithmetic. I was not able to find any algorithm beside
solving the appropriate Diophantine equation. To avoid waisting time
on modulo division I use modified Euclid algorithm based on so called
pseudo-remainder sequences where each dividend is multiplied by an
appropriate power of the leading coefficient of the divisor. This
usually results in growing coefficients of the remainders, but since
we are doing arithmetic modulo some prime, it does not hurt.
Let me describe now, how this algorithm is implemented in QLISP: what
calculations are done in parallel and what synchronizations are
needed.
Here is the abbreviated first version of the program based on qlet. (I
omitted additional details dealing with initialization, termination and
with the primes which generate GCD of too high or too low degree.)
(defun gcd1 (primes)
(let ((prime (car primes)))
(qlet t
((done (gcd1 (cdr primes)))
(cur-gcd (mod-gcd prime)))
(chinese cur-gcd done))))
It is very straightforward. We request that the following two
computations be done in parallel:
the calculation of gcd modulo some prime (we will call it
modulo GCD) by MOD-GCD (one prime is passed as an argument to
it);
the calculation of GCD for the rest of primes and application
of the Chinese theorem to all of this GCDs.
After this is done, we apply the Chinese theorem to our current modulo
GCD and to the result of recursive call to gcd1 (this result already
lifted to be modulo product of (cdr primes). It is obvious that while
calculations of all modulo GCDs are done in parallel, the application
of each Chinese function starts only after the previous application is
finished, and moreover the first application of Chinese theorem is
started only after the last modulo GCD is calculated.
How can we improve this? We would like to arrange the things in a
such manner that after the process finishes with calculating the
modulo GCD it will immediately start applying the Chinese remainder
theorem to this modulo-GCD and the result of the previous application
of the Chinese Remainder theorem. This previous result has to be
passed from the previous invocation of the function GCD1 (see above).
On the other hand this result is not ready yet when the previous
invocation of GCD1 calls next GCD1. To solve this problem, GCD1
passes to its child GCD1 a lambda expression which knows how to
retrieve the result of the previous application of the Chinese
remainder theorem. We still need to do something for synchronization:
we can start calculation of modulo GCD any time, but application of
Chinese Theorem must wait till the previous result being prepared by
the parent GCD1 is ready. The QLAMBDA construct helps us here. My
earlier point of view was that QLAMBDA is overloaded with three more
or less orthogonal and independent properties:
a) being a unit of parallel computation
b) being a monitor
c) being a lexical closure.
But in this case we need all these properties at the same time. So
there is a second version of GCD (it is again an abbreviated version):
(defun gcd2 (retriever primes)
(let ((prime (car primes)))
(let* (cur-gcd
(cur-gcd-handler
(qlambda t (option)
(if (eq option 'retrieve)
cur-gcd
(setq cur-gcd (calc-gcd retriever prime))))))
(no-wait
(funcall cur-gcd-handler 'calculate))
(new-gcd1 cur-gcd-handler (cdr primes) pr-prod))))
For the purpose of the synchronization we want to use the same QLAMBDA
for calculating CUR-GCD and pass it to the child for the purpose of
retrieval of CUR-GCD. RETRIEVER here is an analogous QLAMBDA passed
by our parent, we passes it to CALC-GCD so it will use it to retrieve
previous result after it calculates the modulo GCD and before
application of the Chinese Remainder theorem. It is important that
our child would not be able to apply QLAMBDA that we pass to it,
before we apply it. To achieve this we depend on the existence of a
single construct QLAMBDA, which combines both properties a) and b).
Here is the function calc-gcd:
(defun calc-gcd (retriever prime)
(let ((cur-gcd (mod-gcd prime)))
(let ((prev-gcd (funcall retriever 'retrieve)))
(chinese cur-gcd prev-gcd))))
The same algorithm can be easily implemented using the future construct:
(defun gcd2 (prev-gcd primes)
(gcd2 (future (chinese prev-gcd (future (mod-gcd (car primes)))))
(cdr primes)))
It also can be implemented using the QLET 'EAGER construct if it is
implemented as a futures (meaning that EMPTY location can be assigned
and passed as parameters).
(defun gcd2 (prev-gcd primes)
(qlet 'eager ((cur-gcd (mod-gcd (car primes))))
(qlet 'eager ((cur-chinese (chinese cur-gcd prev-gcd)))
(gcd2 cur-chinese (cdr primes)))))
In the GCD2, each application of the Chinese Remainder theorem started
as soon as the previous results become ready. It would be better if
each application of Chinese Remainder theorem would start as soon as
any two previous results are ready. This would require less
structured parallelism, and to implement this we need to resort to low
level construct of EVENT. Our approach would be as follows: whenever
one modulo GCD is ready, it will be thrown into the pool of partially
lifted GCDs. For each modulo GCD generated (beside the very first
one) we will spawn the new process which will hunt any two GCD,
combine them into one and put the result back into the pool. When the
last process is finished we have GCD.
To preserve the integrity of *GCD-POOL* we use a process closure
(defvar *poll-handler* (qlambda t (handler) (funcall handler)))
(this is analogous to bomb-handler in the paper on QLISP). By passing
the appropriate lambda expression as an argument, this process closure
can be used either to push one modulo gcd onto the *GCD-POOL* or it
can be used to retrieve two modulo gcd to be used by application of
the Chinese Remainder theorem. Here is a new version of GCD (GCD3)
(defun gcd3 (primes)
(let ((prime (car primes)))
(no-wait
(funcall
(qlambda t ()
(let* ((gcd-pair (funcall *poll-retriever*))
(cur-gcd (chinese (car gcd-pair) (cdr gcd-pair)))
(funcall *poll-handler*
#'(lambda ()
(push cur-gcd *gcd-poll*)))
(signal-event *non-empty*)))))
(no-wait
(funcall
(qlambda t ()
(let ((cur-gcd (mod-gcd prime)))
(funcall *poll-handler*
#'(lambda ()
(push cur-gcd *gcd-poll*)))
(signal-event *non-empty*)))))
(gcd3 (cdr primes)))))
Here we immediately spawn the process which eventually will apply the
Chinese Remainder theorem after retrieving two modulo gcd using
*poll-retriever*, then we spawn another process to do calculation of
one modulo gcd and to push it onto *gcd-pool*.
The first process must wait till two modulo gcd are ready and it uses
*non-empty* event (as counting semaphore). Since more than one such
process can wait for the count two and each of them could be waken up,
but only one should, we channel the "wait" through another process
closure *pool-retriever*.
(defvar *pool-retriever*
(qlambda t ()
(wait-event *non-empty* :count 2)
;; account for removal
(signal-event *non-empty* :count -2)
;; retrieve
(funcall *poll-handler*
#'(lambda () (cons (pop *gcd-poll*) (pop *gcd-poll*))))))
Therefore such spawn process first waits for its turn to apply
*pool-retriever* and then the process waits inside *pool-retriever*
for the two modulo gcd to become ready.
The use of both *pool-handler* and *pool-retriever* here is strictly
as a monitor (protector of particular data objects or synchronizer for
particular operations) but not as a unit of parallel execution.
Moreover they are executed strictly sequentially with the calling
process.
Notice a non-orthodox use of negative count in the signal-event.
The synchronization in the above program becomes quite messy. How can
we streamline it?
Our problem induced by the fact that the processes responsible for the
application of the Chinese theorem are generated too early and have to
wait while appropriate GCDs will be ready. Modulo GCDs produced by
application of MOD-GCD and by application of CHINESE, but we have to
generate new Chinese process only for half of them (minus 1).
Therefore if we give a chance to generate new Chinese process to each
of them, then each of them could afford to skip generation of Chinese
process if it is too early, knowing that somebody else will generate
this process.
Actually we move this generation into *pool-handler*. Now
*pool-handler* saves the first, third and etc. modulo GCDs, and
whenever the second, fourth and etc. GCDs arrive, *pool-handler* spawn
a new Chinese process giving it the currently arrived even numbered
GCD and the previously arrived odd numbered GCD.
(defvar *pool-handler*
(qlambda t (cur-gcd)
(if *gcd-pool*
(let ((prev-gcd (pop *gcd-pool*)))
(no-wait
(funcall *pool-chinese* cur-gcd prev-gcd)))
(push cur-gcd *gcd-pool*))))
Here is the definition of *pool-chinese*:
(defvar *poll-chinese*
(qlambda t (cur-gcd prev-gcd)
(let ((new-gcd (chinese cur-gcd prev-gcd)))
(funcall *poll-handler* new-gcd))))
It applies chinese and then calls *pool-handler* to handle the new
modulo GCD.
The synchronization become much easier.
Here is the definition of the new version of GCD:
(defun gcd4 (primes)
(let ((prime (car primes)))
(no-wait
(funcall
(qlambda t ()
(let ((cur-gcd (mod-gcd prime)))
(funcall *poll-handler* cur-gcd)))))
(gcd4 (cdr primes))))
Here is the timing for calculating the GCD for two polynomials of
degree 32 with the degree of GCD being 16:
for GCD1 - 344 ms
for GCD2 - 336 ms
for GCD3 - 347 ms
for GCD4 -345 ms
All of them quite close and the effective use of CPU close to 2.5 (out
of 4).
The fact that timings for GCD1-GCD4 are so close shows that
application of Chinese theorem requires only relatively small amount
of CPU time, this probably is due to the fact that coefficients are
not large. I was not able yet to try polynomials with large coefficients
because of the bignum bug in QLISP.
∂27-Jan-88 1518 MPS expenses
Your trip to Japan was covered with ER2172016 by
Rutie dated 4-24-87. It was somewhat over 4K.
Did you receive that amt?
Pat
∂27-Jan-88 1727 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software Subcommittee Reminder
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 17:27:09 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA04143; Wed, 27 Jan 88 17:26:45 PST
Date: Wed, 27 Jan 88 17:26:45 PST
From: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Message-Id: <8801280126.AA04143@nutmeg.Berkeley.EDU>
To: cweissman@dockmaster.arpa, hearn@rand-unix.arpa, jmc@sail.stanford.edu,
mchenry@guvax.BITNET, ouster@nutmeg.Berkeley.EDU
Subject: Software Subcommittee Reminder
This is just a reminder that I'm expecting position statements from all
of you for the software subcommittee by this coming Friday (1/27) at
5:00 P.M. Since no-one but Tony Hearn has contacted me with any
problems meeting the deadline, I'm assuming that you'll all be able
to get stuff to me in the next 2 days.
I thought it might help for me to "prime the pump" with some position
statements, so here are some that have occurred to me. I know
relatively little about the international software scene, so these
statements are either raw bias or things that I've heard from other
people around here.
Topic #1: basic technology trends
---------------------------------
1. At least in the mainstream areas of computing, there appears to me
to be a strong trend towards commodity packages used by thousands or
hundreds of thousands of people. Lotus 1-2-3, OS/2, and HyperCard are
examples of this.
2. The world appears to be much more amenable to standards these days
than 5-10 years ago, both at the hardware and software levels. Examples
are the IBM PC architecture, Ethernet, UNIX, and X Windows. Proprietary
software and hardware architectures are nowadays viewed with much more
suspicion. Apple's Macintosh looks to me to be the best (only?) example
of a proprietary architecture that is doing well, and even they've been
opening up the system to make it easier for people to add onto it. For
example, Apple is essentially giving away HyperCard, in order to encourage
people to build stacks for it.
3. There appears to me also to be a trend towards international software
(programs and/or systems that can be used with many different national
languages). I don't have much personal experience with this, but I know
two examples: a) H-P is investing a lot of effort to internationalize
its UNIX system, and b) HyperCard claims (eventually) to support different
languages through automatic translation mechanisms.
Topic #2: breakthrough possibilities
------------------------------------
1. I'm skeptical that there will be any major breakthroughs in
software in the next 10-20 years. For example, it appears to me that
the AI stuff that was heralded in the early 80's has not materialized
as hoped, and its future looks much less exciting than it used to (I
hope John M. will be able to support or contradict this claim in more
detail).
2. The most interesting possible breakthrough that I can see is in the
area of software for parallel machines: new paradigms for programming
concurrent machines, and new ways of hiding parallelism so that programmers
don't have to deal with it. I'm skeptical that there will be a major
breakthrough, though.
3. Other possible breakthrough areas that have been suggested to me:
- transferring current software technology from computer scientists
to other scientists to improve their productivity;
- user interfaces, non-procedural languages, higher-level programming
languages; spreadsheets and HyperCard are two examples from the
last 10 years, and there will probably be more examples in the
next 10.
Topic #3: national players
--------------------------
1. My personal impression, and what I've heard from people around here,
is that the U.S.A. is pretty clearly the world leader in software. We
are the largest producer of software, the largest exporter of software,
and we are completely self-sufficient in the software area.
2. However, the software scene is becoming more international. Japan
appears to present the most serious threat. Most of their software
effort is in applications, for example, banking systems, nuclear plant
controls, and computer-aided design tools. Apparently the Japanese work
very closely with customers and produce high-quality software which they
GUARANTEE for their customers. The Japanese 5th-Generation project does
not appear to have produced any great breakthroughs.
3. Many other countries are starting to target the software area. Some
that I've heard of are Taiwan, Malaysia, France, and Britain. None of them
appears to pose a major threat yet.
Topic #4: protectability
------------------------
1. I think that software is essentially impossible to protect. Diskettes
are too small, too easy to hide, and too easy to replicate. Many U.S.
manufacturers have given up on trying to copy-protect their software
because it's not effective and generates hostility in customers.
2. The only way to protect software is to keep the sources proprietary
and only distribute binaries. However, the trend towards public-domain
standards, such as X and (almost) UNIX, may make this unworkable. Even
so, if a binary gets out and a country can clone the hardware, it can
still run the program.
3. The best hope for protecting software is to protect the hardware on
which it runs.
∂27-Jan-88 1830 JK
To: JMC, NSH
∂25-Jan-88 1745 JMC report for nsf
We need a final report for NSF on the grant "Mechanical Theorem Proving
and Development of EKL". One or two pages will do. They probably won't
give us the continuation without it.
---------------
This is mysterious; I discussed this at least twice with Les during
the last 6 months. Anyway, a part of our curren proposal can be used
for this purpose; Shankar can provide it.
JK
∂27-Jan-88 1833 NSH
To: JK, JMC
I'll extract the appropriate part of the current proposal.
I agree that it should serve the purpose.
Shankar
∂27-Jan-88 2142 RPG DARPA and Qlisp
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
IGS@SAIL.Stanford.EDU, edsel!arg@LABREA.STANFORD.EDU
Folks: I was at DARPA yesterday and talked to the following people about
Qlisp:
Steve Squires, Bill Scherlis, Mark Pullen, and Brian Boesch. Mark Pullen
hasd been acting as program manager, but Brian Boesch now is. They all
seemed at least relatively happy with the work, and Bill and Mark were
very happy. Brian is new to DARPA, so there might be some delays associated
with getting the situation cleared up.
It seems that Pucci has been informed to grant the no-cost extension.
According to the Lucid accounting, there is about $220k-$250k left over
to complete the Lucid portion of the first 18 months, which should hold
Lucid until the summer. Boesch thought that the Stanford portion had been
spent already, and this could cause a problem, because it is not believed that
the renewal can be fully processed and granted until the summer. There was
some question about the CSD tasking contract, which needs to be in
place before Qlisp money can arrive.
Boesch will be in the area next week, and he asked me to set up a meeting
for next Wednesday evening (at Lucid). He wants to get a briefing on
the work and the proposal for the next 18 months. He will try to straighten
out our woes as fast as he can, and having a feeling for the project will
help.
Can you all confirm that you can make it next Wednesday? We will make it
a supper meeting.
-rpg-
∂27-Jan-88 2155 rivin@Gang-of-Four.Stanford.EDU DARPA and Qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:55:22 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04673; Wed, 27 Jan 88 21:55:17 pst
Date: Wed, 27 Jan 88 21:55:17 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8801280555.AA04673@Gang-of-Four.Stanford.EDU>
To: RPG@SAIL.Stanford.EDU
Cc: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU,
edsel!arg@LABREA.STANFORD.EDU
In-Reply-To: Dick Gabriel's message of 27 Jan 88 2142 PST <8801280543.AA04657@Gang-of-Four.Stanford.EDU>
Subject: DARPA and Qlisp
Sure, wednesday evening is fine with me. Do we need to take care of
the logistical details, or are you (Dick) taking care of this?
(logistical details=where?when? how?)
∂28-Jan-88 0851 HART@KL.SRI.COM Re: mailing address
Received: from KL.SRI.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 08:50:55 PST
Date: Thu 28 Jan 88 08:51:50-PST
From: Peter Hart <HART@KL.SRI.COM>
Subject: Re: mailing address
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 26 Jan 88 12:39:00-PST
Message-ID: <12370235272.29.HART@KL.SRI.COM>
should be KL.SRI.COM --Peter
-------
∂28-Jan-88 0900 JMC
Stanford contracts office
∂28-Jan-88 0916 MPS nomination
Fred Seitz, Rockefeller Univ called (212-570-8423) regarding
person for Japanese award. He will call you at home.
Pat
∂28-Jan-88 0942 ullman@navajo.stanford.edu action item?
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 09:42:44 PST
Received: by navajo.stanford.edu; Thu, 28 Jan 88 09:38:42 PST
Date: Thu, 28 Jan 88 09:38:42 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: action item?
To: dek@sail.stanford.edu, guibas@dec.src.com, jmc@sail.stanford.edu,
pratt@score.stanford.edu, rwf@sail.stanford.edu, zm@sail.stanford.edu
Perhaps we should consider the following action item.
Invite Nick Pippenger to send us his resume and start to build a case,
either fully in CS or join with OR.
Invite Maria Klawe to send her resume, with a promise that we will
try to make a case for an appointment at Stanford, jointly with
Math, OR, or anybody else who will listen, but at most 1/3 in CS.
I am going on the assumption that the case for Pippenger will be excellent
and on Joe Halpern's belief that a case that Klawe is of Stanford
quality in discrete mathematics can be made.
---jeff
∂28-Jan-88 1003 chapman@russell.stanford.edu Andrei Ershov
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 10:03:44 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 28 Jan 88 10:06:53 PST
Date: Thu, 28 Jan 88 10:06:53 PST
From: chapman@russell.stanford.edu (Gary Chapman)
To: mccarthy@sail.stanford.edu
Subject: Andrei Ershov
Professor McCarthy,
I spent some time with a delegation of Soviets who were visiting Stanford
this week, and one of them told me that Professor Ershov has been diagnosed
as having terminal cancer. I know that you are a friend of Professor Ershov,
so I was wondering if you could tell me anything more about his condition.
I spent several days in Professor Ershov's company in Italy last October,
and we became quite fond of each other, I think. This news is very tragic,
and I would like to send my regards to him, bt I don't want to pass on
such feelings without first confirming the report I heard this week.
Thanks,
-- Gary Chapman
Executive Director, CPSR
chapman@russell.stanford.edu
∂28-Jan-88 1011 MPS nsf
Please call Thomas Shockley (NSF) 202-357-7350
thanks
pat
∂28-Jan-88 1119 chapman@russell.stanford.edu re: Andrei Ershov
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 11:19:00 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 28 Jan 88 11:22:10 PST
Date: Thu, 28 Jan 88 11:22:10 PST
From: chapman@russell.stanford.edu (Gary Chapman)
To: JMC@SAIL.Stanford.EDU
Subject: re: Andrei Ershov
Cc: chapman@russell.stanford.edu
Thanks for your reply. I agree wholheartedly with your feelings about
Ershov. We were having dinner together in Italy, and he volunteered the
information that he had been called into the Kremlin just before leaving
for Italy. He was called by Ligachev, the number two man in the Politburo,
something of a rival to Gorbachev, and the man known to be the most resist-
ant to "perestroika" and "glasnost." Ershov told me that Ligachev asked
him what he would most like to see happen in the Soviet Union. Ershov told
me his answer to this question, which surprised me. He said he told Liga-
chev that he would like to see the government allow the telling of the
country's "anti-history," as he put it. He said we all know our "history,"
but we don't know our "anti-history"--the stories of Stalinist purges and
executions, the Ukraine famines, the behavior of the Red Army in Afghanistan,
etc. I thought this was a curious wish from a scientist who was ostensibly
asked what he would do if he found a genie in a bottle. Moreover, it was
such a bold answer, courageous to the point of bordering on foolishness,
that I saw the small computer scientist quite differently from that point
on.
I actually went to Italy to meet Ershov--it was his attendance at a confer-
ence on arms control that made me consider it important enough to attend
myself. We had corresponded before meeting, but our correspondence was
rather formal. A funny thing happened before we met. A mutual friend, a
famous computer scientist, saw Ershov in Europe and somehow they got onto
discussing me. Ershov by this time knew that I was travelling to Italy to
meet him. He said that he had discovered that I am a former "Green Beret,"
which is apparently a form of military service that has a reputation in the
Soviet Union even worse than in the States. He told this friend of ours
that he was a little concerned about this, that his government might view
our meeting as imprudent--he said there was a general admonition to Soviets
allowed to travel that they should not associate with "disreputable people"!
I found this quite amusing.
The whole thing evaporated when we did meet in Italy. We spent a lot of time
together, to the point where the Italian conference organizers found it a
relationship symbolic enough to set dozens of reporters on us--Ershov and I
conducted a joint "interview" together for the Italian press, more like a
"point-counterpoint" session. The last night of the conference we were filmed
together by Italian TV.
Ershov told me the last night we were together that he had informed Velikhov,
Gorbachev's top science advisor, that he--Ershov--and I would be meeting in
Italy. Ershov told me that Velikhov had asked him to report back on our
discussions. One of the reasons I decided to seek out Ershov was that we had
corresponded about the possibility of his joining the editorial board of a new
journal I am editing. I had hoped that Ershov would give me an affirmative
answer to this proposition in Italy. Instead he told me that he was to report
back to Velikhov about our meeting, and discuss with him the possibility of
participating in this journal's work. One of the last things he said to me
was that he would report to Velikhov that his participation on the editorial
board was a "fait accompli"--that there was nothing for Velikhov to decide,
it was all finalized. Ershov was supposed to get back in touch with me as
soon as he returned to Novosibirsk.
I didn't hear from him again, despite writing to him twice after returning from
Italy. This gives the report about his illness more credence. Also, the
story came from two Soviet specialists in AI, Viktor Sergeev and Gennady
Kochetkov, both of whom work for Velikhov. Apparently whatever Ershov re-
ported about our discussions in Italy did not preclude Velikhov's own
subordinates to call me when they came to Palo Alto. Both Sergeev and Kochetkov
told me that there was no point trying to communicate with Ershov, he is too
ill to reply.
I am going to try and track down the veracity of this report. I will let you
know what I learn. Thanks again for your reply.
-- Gary Chapman
∂28-Jan-88 1129 VAL Ed Brink
Ed Brink expects from you some sort of reaction to the progress report he sent
you earlier this month, and he asked me to remind you about it. Here is his
summary of what he'd like you to do:
> He has an official recommendation-letter form (or should have, if they didn't
> send it to Texas; I put it in his box in late December). So I'm expecting he
> will act on it one way or another, and if it makes sense to tell me to do
> something, he will (I presume) do so. I'd like some sort of clue to what state
> I'm in; if he really likes the work, that's one thing, and if he hates it,
> that's another. In either of those cases I don't have to do anything now, but
> knowing which it is will help me start preparing for the future. In the middle
> case, if I need to do more on the project, the sooner I know the better I can
> try to plan for it.
> So: I'd like him to write the letter and if possible let me know its general
> content. I'd also like a grade in CS399, but since it's not on my proposal any
> more I don't know how urgent that is.
My summary of the progress he's made:
The assignment was to implement the inverse method. He spent a lot of time
studying the inverse method (as described in my paper) and MRS, and documenting
them more formally. But he hasn't really done any serious coding so far.
∂28-Jan-88 1122 coraki!pratt@Sun.COM Re: action item?
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 11:22:12 PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA00510; Thu, 28 Jan 88 11:22:40 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA21614; Thu, 28 Jan 88 11:00:34 PST
Received: by (4.0/SMI-4.0Beta)
id AA12662; Thu, 28 Jan 88 10:45:52 PST
Date: Thu, 28 Jan 88 10:45:52 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801281845.AA12662@>
To: Jeff Ullman <ullman@navajo.stanford.edu>
Cc: dek@sail.stanford.edu, guibas@dec.src.com, jmc@sail.stanford.edu,
pratt@score.stanford.edu, rwf@sail.stanford.edu, zm@sail.stanford.edu
Subject: Re: action item?
In-Reply-To: message of Thu, 28 Jan 88 09:38:42 PST.
<8801281744.AA27809@Sun.COM>
I could live with that distance.
-v
∂28-Jan-88 1207 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:06:58 PST
Date: Thu 28 Jan 88 11:58:27-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12370269242.48.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
NOTE: Dr. Lamport's talk had to be postponed.
THERE WILL BE NO MEETING TOMORROW, JANUARY 29!
February 5: Prof. John Mitchell (Stanford Univ.),
"Introduction to Polymorphic Lambda Calculi"
February 12: Dr. Leslie Lamport (DEC-SRC),
"What Good is Temporal Logic?"
-------
∂28-Jan-88 1240 Qlisp-mailer Parallelizing Functional Programs with Qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:40:36 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05768; Thu, 28 Jan 88 12:40:48 pst
Date: Thu, 28 Jan 88 12:40:48 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8801282040.AA05768@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Cc: pehoushek@gang-of-four
Subject: Parallelizing Functional Programs with Qlisp
For those of you who received a preliminary copy of my report at the meeting
yesterday, the following text contains a more complete table. I extracted the
text from the current version of the report.
***********************
\begin{verbatim}
;;; RPG's TAK, with QFUN reader macro added at the key point.
(defun qtak (x y z)
(if (not (< y x))
z
#!(qtak (qtak (1- x) y z)
(qtak (1- y) z x)
(qtak (1- z) x y))))
;;; The standard serial definition of FIB, parallelized by #!.
(defun fib (n)
(if (< n 2)
n
#!(+ (fib (- n 2)) (fib (1- n)))))
\end{verbatim}
The analysis of these two functions considers four cases for any
particular input. To estimate how costly it is to evaluate the
N-STACK-EMPTY-P predicate, we ran a serial version of the code
(without using QFUN or its predicate). Then we ran the parallel code
in serial mode, so that the predicate always got evaluated and the
answer was such that no processes ever spawned. The next columns show
the 2, 3 and 4 processor running times, each using the above code.
All times are in seconds. In the case of (TAK 18 12 6), there is a
well-known set of results on a variety of machines to be found in RPG.
The last three columns contain the speedup ratios. We divided P1's
running time by Pn's running time to obtain the speed-up. It is fair to
use P1's running time because the predicate would be very cheap to evaluate
in a pipelined architecture, by just testing a control bit in the CPU, etc.
\begin{verbatim}
Serial Para/1 Para/2 Para/3 Para/4 P1/P2 P1/P3 P1/P4
FIB 20 .229 .261 .144 .108 .086 1.81 2.42 3.03
FIB 25 2.528 2.858 1.444 .997 .838 1.98 2.53 3.41
FIB 30 28.094 31.654 15.708 10.624 8.282 2.02 2.98 3.82
FIB 35 310.859 351.186 119.801 173.860 91.224 2.02 2.93 3.85
TAK 18 12 6 .600 .640 .353 .260 .210 1.81 2.46 3.05
TAK 20 12 4 23.507 24.382 12.446 8.582 6.729 1.96 2.84 3.62
BOYER 10.671 11.244 6.444 4.907 4.057 1.74 2.29 2.77
BOYER2 37.133 19.642 14.815 12.290 1.89 2.51 3.02
BOYER3 43.372 21.418 17.058 13.738 2.02 2.54 3.15
\end{verbatim}
The BOYER benchmark REF RPG is a more typical large lisp computation.
In order to run this benchmark, the code was modified to eliminate the
use of special variables. This made the program more functional, and
also speeded it up quite a bit. The QFUN macro was then added at just ONE
key spot in the code. Not surprisingly, this spot was also a recursive
function invocation. Other key spots may have to be found to boost the
speed-up ratio closer to the theoreticl limit. BOYER2 and BOYER3 had
slightly larger tautologies to prove than in BOYER.
∂28-Jan-88 1329 ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu re: Lunch
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 13:29:28 PST
Received: by lindy.stanford.edu; Thu, 28 Jan 88 13:30:16 PST
From: ELLIOTT%SLACVM.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Thu, 28 Jan 88 13:20:21 PST
Date: 28 Jan 88 13:19 PST
To: JMC@sail.stanford.edu
Subject: re: Lunch
Date: 28 January 1988, 13:18:13 PST
From: Bloom, Elliott ELLIOTT at SLACVM
To: JMC at SAIL.STANFORD.EDU
Subject: re: Lunch
In-Reply-To: JMC AT SAIL.STANFORD.EDU -- 01/28/88 01:21
That is fine with me. Shall we make it at 12noon at the faculty club?
I will make the reservation.
∂28-Jan-88 1416 simpson@vax.darpa.mil Re: Feb 17 visit
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 28 Jan 88 14:16:20 PST
Received: from sun35.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA22344; Thu, 28 Jan 88 17:04:31 EST
Posted-Date: Thu 28 Jan 88 16:59:15-EST
Received: by sun35.darpa.mil (5.54/5.51)
id AA07864; Thu, 28 Jan 88 16:59:17 EST
Date: Thu 28 Jan 88 16:59:15-EST
From: Bob Simpson <SIMPSON@vax.darpa.mil>
Subject: Re: Feb 17 visit
To: nilsson@tenaya.stanford.edu
Cc: schwartz@vax.darpa.mil, simpson@vax.darpa.mil,
ENGELMORE@sumex-aim.stanford.edu, jmc@sail.stanford.edu,
val@sail.stanford.edu, genesereth@score.stanford.edu,
ginsberg@sushi.stanford.edu, shoham@score.stanford.edu,
latombe@coyote.stanford.edu, binford@coyote.stanford.edu,
FEIGENBAUM@sumex-aim.stanford.edu, levinthal@sierra.stanford.edu,
stan@ai.sri.edu, buckley@score.stanford.edu,
friedland@sumex-aim.stanford.edu
Message-Id: <570405555.0.SIMPSON@VAX.DARPA.MIL>
In-Reply-To: <8801232216.AA23803@Tenaya.stanford.edu>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
Nils: We've reviewed the draft agenda and find it quite agreeable. You all
have dona a remarkable job of "design and packaging" to meet our time
constraints. Well done! -- Bob
-------
∂28-Jan-88 1621 Qlisp-mailer GNU Emacs customizations for Qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 16:18:45 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06242; Thu, 28 Jan 88 16:19:00 pst
Date: Thu, 28 Jan 88 16:19:00 pst
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8801290019.AA06242@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: GNU Emacs customizations for Qlisp
Here are some useful forms to put in your .emacs file:
(setq completion-ignored-extensions
(append '(".qbin" ".qlap") completion-ignored-extensions))
(put 'qlet 'lisp-indent-hook 2)
(put 'qlambda 'lisp-indent-hook 2)
The "completion-ignored-extensions" lets a filename complete to .lisp
when there are both .lisp and .qbin (or .qlap) versions. The
"lisp-indent-hook" properties cause indentation as in the following
examples:
(qlet (foo) ((w x)
(y z))
body)
(qlet (foo)
((w x)
(y z))
body)
(qlambda (foo) (x y)
body)
(qlambda (foo)
(x y)
body)
∂28-Jan-88 1720 simpson@vax.darpa.mil re: AI and Formal Reasoning Proposal
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 28 Jan 88 17:20:43 PST
Received: from sun35.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA22961; Thu, 28 Jan 88 20:21:34 EST
Posted-Date: Thu 28 Jan 88 20:16:54-EST
Received: by sun35.darpa.mil (5.54/5.51)
id AA07967; Thu, 28 Jan 88 20:16:57 EST
Date: Thu 28 Jan 88 20:16:54-EST
From: Bob Simpson <SIMPSON@vax.darpa.mil>
Subject: re: AI and Formal Reasoning Proposal
To: JMC@sail.stanford.edu
Cc: SIMPSON@vax.darpa.mil
Message-Id: <570417415.0.SIMPSON@VAX.DARPA.MIL>
In-Reply-To: <8801260044.AA12846@vax.darpa.mil>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
John: I recieved the needed info today, thanks! -- Bob
-------
∂28-Jan-88 1815 JK books
Just read an interesting book on cultural pessimism and UOA's (university
oriented americans) by Max Singer, "Passage to a Human World", published
by the Hudson Institute. You might find it amusing.
∂28-Jan-88 1843 Qlisp-mailer fib
To: qlisp@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Here are some remarks/questions on the paper by ARG and RPG.
(1) Has anyone compared the simple recursive qfib with depth cutoff
which continues to test for cutoff after it has been reached
vs qsfib which calls serial fib after the cutoff point has
been reached?
(2) If I interpret the charts for depth cutoff qfib correctly
it seems that one has only a factor of 2 to 10 of slop in
choice of depth. The allowed slop seems to get bigger for
bigger n in the fib problem, but certainly doesn't seem to
justify factors of 100 or 1000 as John has been claiming. Comments?
(3) About qfib that uses the qempty test --
are the results equally bad for larger n?
What if one uses (< qsize m) for some m (maybe the
number of processors)?
When I tried to understand the results, the crude explaination
I came up with is that when a the process que becomes empty
it is equally likely that any of the current qlets will find
it empty and since there are exponentially more qlets at
the (fib 2) level than at (fib n) they win. But it seems to
me that this model predicts that n queues will have the same
problem -- slightly offset. So, is my reasoning wrong or
have we just not looked at large enough fibs to show this,
or ...?
∂28-Jan-88 1908 helen@psych.Stanford.EDU Hi there and correction
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 19:08:12 PST
Received: by psych.Stanford.EDU (3.2/4.7); Thu, 28 Jan 88 19:07:22 PST
Date: Thu, 28 Jan 88 19:07:22 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Hi there and correction
Cc: helen@psych.Stanford.EDU
I was off by a factor of 10 on the number of words a 5-year-old knows.
But I was not far off, for the number of words per day. The total at
5 years is close to 10,000 which works out to about 8 words per day
over the course of 3.4 years (say, from 1.6 to 5 years of age). Pretty
impressive! Unfortunately I haven't a good memory for details. Glad
you caught me on that; maybe I'll remember it now!
-helen
∂28-Jan-88 2033 edsel!arg@labrea.Stanford.EDU proposed additional Qlisp tasks
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 20:33:13 PST
Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 20:33:25 PST
Received: from bhopal.lucid.com by edsel id AA28130g; Thu, 28 Jan 88 19:09:18 PST
Received: by bhopal id AA00659g; Thu, 28 Jan 88 19:13:14 PST
Date: Thu, 28 Jan 88 19:13:14 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8801290313.AA00659@bhopal.lucid.com>
To: jmc@sail.Stanford.EDU, air@Gang-of-Four.Stanford.EDU
Cc: rpg@sail.Stanford.EDU, edsel!tony@labrea.Stanford.EDU
Subject: proposed additional Qlisp tasks
Here are two groups of tasks to be done by Lucid over the second 18 months
of the Qlisp contract. The first is what can be done based on the original
Qlisp budget and the second assumes additional support. We'll plan on
presenting this to Brian Boesch when he's here at Lucid next Wednesday.
If you send a proposal of to Squires, please also send copies to the other
DARPA folks: Bill Scherlis, Mark Pullen, and Brian Boesch.
Ron
I. Tasks to be done by Lucid with the current funding level: (1 person)
(All in the original Qlisp contract)
1) Non-local exits via CATCH and THROW will be implemented.
2) The EAGER forms of QLET and QLAMBDA constructs will be implemented
along with explicit futures.
3) Some minimal performance-monitoring tools will be written.
4) System tuning to improve Qlisp performance.
II. Additional tasks to be done by Lucid given increased funding: (5 people)
1) Additional language constructs will be added to Qlisp based
on experience using it.
2) Improved memory management: This includes investigating garbage
collection algorithms that take advantage of multiple processors.
Various possibilities such as incremental, ephemeral, and parallel
garbage collection methods will be examined, and the most promising
one implemented. Also part of this research would be to look at
improved memory allocation methods, for example a separate consing
area per process or per processor.
3) Port Qlisp to other computer systems: The Encore machine appears
to be an emerging popular research machine. We propose to port to
the Encore the basic Lucid Common Lisp extended to include futures
so that we can implement both Qlisp and Multilisp on top of it.
This will allow us to investigate different parallel language features
from a common base environment. This effort will also tie in with
the Lisp work that Encore is currently doing. In particular:
(a) Porting to Encore under MACH will be done.
(b) Distributed extensions under MACH will be done.
(c) Multitasking will be evaluated under MACH, so that parallel
programs can be run on uniprocessors.
4) Solutions to the garbage collection of processes: In the Qlisp
environment it is possible to spawn a process that might stay active
even after all the other processes that could reference it have gone
away. This abandoned process may still be consuming system resources,
and should be killed. Lucid will investigate detecting such processes
and automatically killing them when necessary.
5) Debugging aids: The initial contract only calls for Lucid to develop
rudimentary debugging tools. We propose to expand our work here and
develop debugging tools that will aid programmers trying to develop
Qlisp programs. For example, timestamped function trace streams
could be used to study interactions in multiple threads of execution.
This also means extending the basic Lisp debugger to work in a
multiprocessor environment.
6) Performance evaluation: To evaluate how well programs in Qlisp run
requires the development of various monitoring tools to measure
system performance. These tools are necessary to identify system
bottlenecks, determine processor utilization (i.e. degree of
parallelism achieved), measure system overhead, etc.
7) Benchmarks: We will extend the Gabriel Lisp benchmarks to test
performance of parallel Lisps, and to compare this with conventional,
sequential Lisps. We will try to coordinate our work with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
8) Parallel programming tools: Programmers need help in designing,
coding, debugging, and analyzing parallel algorithms. We will try
to ease this burden by providing help wherever possible. This will
include design-stage specification tools, program analysis tools,
possible syntactic changes to Qlisp, user program monitoring tools,
additional parallel debugging facilities, post-mortem analysis tools,
etc.
9) Process scheduling: Qlisp is based on queue-based multi-processing;
when a processor completes a task it goes to the queue for another.
In the initial Qlisp implementation a simple first-in first-out
scheduler is used. We propose to look at more complex, priority-based
scheduling algorithims to determine how useful they would be in the
framework of Qlisp. This would be based on the results of the Stanford
contract work on algorithm design for parallel processing. Some form
of time-slicing each processor may also be investigated.
We estimate that it will take approximately 5 people at Lucid working full
time to accomplish all of the tasks on the above list. Roughly this translates
into $1616K or an additional $1178K. Note that this is only a rough estimate,
I'll get Tony Slocum to run up a real budget early next week.
In addition to increased funding, Lucid will also need access to an Encore
computer.
∂28-Jan-88 2134 JSW Re: QLISP & GCD
To: AIR@SAIL.Stanford.EDU
CC: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
IGS@SAIL.Stanford.EDU, JDP@SAIL.Stanford.EDU
The message on GCD algorithms is very interesting. As I was reading it,
these were some of my thoughts:
1. Of the several versions of GCD2, the one using futures is clearly
most concise and understandable.
2. I don't think that the inner future in the second form of GCD2 will
produce any speedup, because the Chinese remainder procedure has to wait
for its argument anyway. So it can be simplified to
(defun gcd2 (prev-gcd primes)
(gcd2 (future (chinese prev-gcd (mod-gcd (car primes))))))
The third form of GDC2 can similarly do with only one eager qlet instead
of two, but interestingly, changing either eager qlet to t (or nil) is not
correct. What works is to take the expression bound to cur-gcd in the
outer qlet and substitute it where it is used:
(defun gcd2 (prev-gcd primes)
(qlet 'eager ((cur-chinese (chinese (mod-gcd car-primes) prev-gcd)))
(gcd2 cur-chinese (cdr primes))))
2. There are two sources of parallelism: the computation of mod-gcd for
each of the primes can be done concurrently, and the application of the
Chinese remainder procedure can be done on several pairs of results at the
same time. The data dependencies in the Chinese remainder phase take the
form of a binary tree. Any binary tree will work, but I think the least
amount of work is done when a balanced tree is used, because this keeps
the (bignum) coefficients small as long as possible. None of the four
programs currently appears to favor a balanced tree, which may make a
noticeable difference when you start using bignums.
3. GCD1 and GCD2 only take advantage of the first form of parallelism, while
GCD3 and GCD4 attempt to do both. I think there is a bug in GCD4 however, at
least in the version in your message. A single process closure is created
and assigned to *poll-chinese*, and this process will do all of the calls to
the Chinese remainder procedure, but it will do them sequentially.
4. The fact that the times for the four are so close, even though some don't
take advantage of as much parallelism as others, suggests that most of the
time is being spent in the mod-gcd phase and the Chinese remaindering does
not account for much. Again, this may be because bignums aren't used yet.
∂29-Jan-88 0901 GOODMAN%uamis@rvax.ccit.arizona.edu copy request
Received: from rvax.ccit.arizona.edu by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:00:48 PST
Date: Fri, 29 Jan 88 09:29 MST
From: GOODMAN%uamis@rvax.ccit.arizona.edu
Subject: copy request
To: DUANE.ADAMS@c.cs.cmu.edu, BLUMENTHAL@a.isi.edu, DONGARRA@anl-mcs.arpa,
GANNON%RDVAX.DEC@decwrl.dec.com, JAHIR@athena.mit.edu, HEARN@rand-unix.arpa,
JLH@sierra.stanford.edu, JMC@sail.stanford.edu, KNEMEYER@a.isi.edu,
MCHENRY@GUVAX.BITNET, OUSTER@ginger.berkeley.edu, Ralston@mcc.com,
CWEISSMAN@dockmaster.arpa
X-VMS-To: @NAS
Please copy all e-mail message to Blumenthal. She needs to keep a finger
on our "pulse" and some sort of record for posterity. Thanks.
∂29-Jan-88 0903 RPG McCarthy goes to Paris
∂28-Jan-88 1600 edsel!jlz@labrea.Stanford.EDU McCarthy goes to Paris
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 16:00:15 PST
Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 16:00:29 PST
Received: from sunvalleymall.lucid.com by edsel id AA27163g; Thu, 28 Jan 88 15:52:06 PST
Received: by sunvalleymall id AA01371g; Thu, 28 Jan 88 15:56:07 PST
Date: Thu, 28 Jan 88 15:56:07 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8801282356.AA01371@sunvalleymall.lucid.com>
To: labrea!rpg%sail.stanford.edu@labrea.Stanford.EDU,
edsel!rpg@labrea.Stanford.EDU
Subject: McCarthy goes to Paris
I called Mathis. He has not heard from McCarthy directly.
Mathis is assuming McCarthy will be there the same days as you,
arriving 2/21, leaving 2/27. I have not heard back from McCarthy
either. Should I call him or do you want to speak to him?
---jan---
∂29-Jan-88 0911 RICHARDSON@Score.Stanford.EDU Visiting Committee breakfast on 2/3/88
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:11:12 PST
Date: Fri 29 Jan 88 09:06:32-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Visiting Committee breakfast on 2/3/88
To: JMC@Sail.Stanford.EDU
Message-ID: <12370500091.25.RICHARDSON@Score.Stanford.EDU>
Dear Professor McCarthy,
You are invited to attend a presentation to the Visiting Committee at the
Robotics Lab in Cedar Hall on Wednesday, February 3 at 8:15. A continental
breakfast will be served. Please respond to Heidi - richardson@score.
-------
∂29-Jan-88 0934 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
HIERARCHIC AUTOEPISTEMIC THEORIES FOR NONMONOTONIC REASONING
Kurt Konolige (KONOLIGE@BISHOP.AI.SRI.COM)
SRI International
Friday, January 29, 3:15pm
MJH 301
Nonmonotonic logics are meant to be a formalization of nonmonotonic
reasoning. However, for the most part they fail to capture in a
perspicuous fashion three of the most important aspects of such
reasoning: the explicit computational nature of nonmonotonic inference,
the assignment of preferences among competing inferences, and the
specification of how facts with the same semantic content can be used
differentially in inference. We propose a new method of nonmonotonic
reasoning in which the notion of inference from specific bodies of
evidence plays a fundamental role. The formalization is based on
autoepistemic logic, but introduces additional structure, a hierarchy of
evidential subtheories. The method offers a natural formalization of
many different applications of nonmonotonic reasoning, including
reasoning about action, speech acts, belief revision, and various
situations involving competing defaults.
∂29-Jan-88 1050 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu copy of work send to John Ousterhout due today
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 29 Jan 88 10:50:32 PST
Received: by lindy.stanford.edu; Fri, 29 Jan 88 10:51:00 PST
Received: by Forsythe.Stanford.EDU; Fri, 29 Jan 88 10:43:23 PST
Date: Fri, 29 Jan 88 12:45 EST
From: <MCHENRY%GUVAX.BITNET@forsythe.stanford.edu> (I would not be convicted by a jury of my p...)
Subject: copy of work send to John Ousterhout due today
To: jmc@sail.stanford.edu
X-Original-To: cweissman@dockmaster.arpa,hearn@rand-unix.arpa,
jmc@sail.stanford.edu, MCHENRY
To: John Ousterhout and members of the Software Group
From: Bill McHenry
Re: Initial Overview of Systems Software in the USSR
Gentlemen:
There are some gaps here, as you will see. I have taken our four major
areas and have broken some of them down a bit further. The bulk of the
material here addresses the question of basic technology trends.
Identifying those leading national players and their breakthrough
possibilities is harder and will require more research. For this analysis I
am heavily indebted to Peter Wolcott, one of Sy's PhD students at Arizona,
who provided a good deal of the basic analysis which I have embellished and
partially updated here. I address protectability briefly at the end. Please
give me specific feedback on other areas of systems software in the USSR
which you think need to be covered.
PRELIMINARY OVERVIEW OF SOVIET SYSTEMS SOFTWARE
Jan. 29, 1988
William K. McHenry
1. Systems Software
1.a. Operating Systems
The Eastern Block countries have, within this decade, made significant
advances in operating systems for their Unified Series mainframe computers.
Having introduced IBM-like operating systems to take advantage of virtual
storage capabilities in 1979 with OS/ES 6.1 and DOS/ES 3.0, they
implemented virtual machine capabilities comparable to that of IBM's VM/370
in 1982 [Hein84]. Recent efforts, culminating in the release of OS/ES 7.0
in 1985, have focused on consolidating systems components, improving
efficiency and reliability, and increasing telecommunications capabilities
[Wolc86]. It is rumored that some of the efficiency and reliability
enhancements are completely indigenuous, departing from IBM efforts
[Mche86d]. Despite the quantum leaps of the last decade, current mainframe
operating system capabilities do not seem to have progressed significantly
past IBM's 1973 level.
In the minicomputer area, there are a number of DEC operating systems
(RSXs) which run on the SM series machines, along with a few other
operating systems. In spite of the extensive use of DEC-like
minicomputers, the UNIX operating system is used in very few locations.
Only within the last couple of years has a Soviet equivalent of this
system, INMOS, been noted. It does appear, however, that usage of this
system has been greater than might be expected given its recent
introduction [Bely84d; Ivan86]. The most significant usage of a UNIX type
system has been on the MARS parallel processor, which some have called the
Soviet 5th generation project [Wolc86c]. It is not known to what degree
the MARS operating system contains the collection of software development
tools that have helped make UNIX so popular in the West.
It appears that CP/M and MS-DOS have been given the nod as standards for
micros, but here too there is considerable diversity. A fair amount of
processing continues on second generation machines such as the BESM-6 and
the Minsk-32, each of which have indigenous operating systems. A good
deal of effort is going into systems software for the El'brus series of
supercomputers, which are the successors of the BESM-6.
The US appears to be ahead with respect to widely used operating systems,
and the gap may be widening, but not appreciably. This is because
continuing development of this type of system is hampered by the need to
maintain upward compatibility for the large user community dependent on
existing systems. IBM's efforts with the MVS operating systems is a case in
point. The Soviets have made huge progress by reaching the level of MVS and
VM operating systems. Further capabilities will come along only when the
delayed ES-III series of mainframes makes its appearance. In addition,
there is a much greater diversity of operating systems in use in mainframe
installations throughout the country. DP shops do not simply go to the new
release and get all their software upgrades. Often earlier releases have to
be brought up in order to run specific packages. There are even computer
centers that reject multiprogramming because of economic incentives to do
so.
In the West a great deal of effort is going into development of new
operating systems for small user communities and of special purpose
operating systems for, for example, distributed systems and parallel
architectures. Comparatively little work is going on in the USSR in
practice in these areas, partly because of the paucity of machines
available to the academic community.
The main national player for development of the Ryad (IBM) operating
systems is the Scientific Research Center of Electronic Computer Technology
(NITsEVT) in Moscow. The main national player for the development of
UNIX-like operating systems and the PDP-11 type operating systems for the
SM series is the Institute of Electronic Control Machines (INEUM) in
Moscow and its new parent, the Institute of Informatics, also in Moscow.
The main player for operating systems for the HP line of SM computers and
the PS series of vector processors is probably the Severodonetsk IMPULS
association.
1.b. Programming Languages
Fortran is the most widely used programming language for science and
engineering applications in the USSR; and PL/1, for business applications
[Wolc86c]. While quite a number of indigenous third generation languages
have been developed over the years in the Soviet Union, most of these are
Algol-like and are in rather limited use. Some innovative steps have been
taken in the areas of fourth generation languages and parallel processing
languages (see below).
Ada has been available in the Soviet Union since 1984, and a Russian
version of that language, RADA, has been under development as well
[Lipa85b]. It is not known how complete or how efficient these compilers
are. Ostensibly, the language was developed simply to provide standard
software for computers of all sizes within the country. Given the
special concurrent processing features of the language, however, it is only
natural to assume that in the USSR it will be used to develop applications
for real-time embedded systems, as is intended in the United States. No
such Ada systems are known to exist yet, however. The Hungarians have also
put considerable effort into developing Ada compilers for a variety of
machines.
Given the limited use of UNIX-like operating systems, it is not surprising
that C is not in wide-spread use in the Soviet Union. What is significant,
however, is that this language is the primary software development language
for the current, uniprocessor, version of the MARS computer [Wolc86c]. If the
UNIX-based software development environment for MARS is as rich as UNIX
environments are wont to be, then the potential exists for the creation of
some significant software systems that could be modified to run on future,
multiprocessor MARS systems as these become available.
Developments in fourth generation languages (4GL) have been primarily in
query languages and automatic programming systems. Several institutes are
doing research in natural language interfaces with a fair degree of
success. Several automatic programming systems such as PRIZ and DAILOS
have come into relatively widespread use in the Soviet Union [Ros85; Wolc86c].
PRIZ, the most widely used system of this nature is based on the principles
of logic programming and as a result is not suitable for building large
software systems in which the problem domain is not well understood. It
requires a very precise specification of that domain and is hampered by
poor facilities for specifying the flow of control. Only a few of these
systems contain mechanisms for insuring the internal consistency of code
that, for example, are contained in the USE.IT system of Higher Order
Software, Inc [Koto84]. Next to nothing has been seen of such decision
support tools as spreadsheets. Partially because of lack of end-user access
to computing facilities, Soviet efforts in 4GL have not been geared toward
enabling non-professional end-users to develop useful programs, but rather
toward assisting trained DP personnel.
Third generation languages have been in stable existence long enough for
the Soviets to implement them on their own systems. In both the West and
the Soviet Union, Ada is still emerging, although it is fair to say that a
whole lot more effort is going into Ada here. In theoretical terms with
respect to third generation languages, there is probably parity. In
practical terms, a lot more development is going on here because of the
ready availability of cheap, reasonably powerful languages and
mini-environments such as Borland's languages and the proliferation of
access to machines.
Work in natural language query languages and automatic programmers
(PRIZ) notwithstanding, the Soviets are falling behind in 4GL chiefly
because in the West 4GL are intended to increase the productivity of a
widespread and relatively unsophisticated user community. Hence the
popularity of such 4GL as spreadsheets. The size of this market has fueled
much development in the software development industry. Comparable
development in the Soviet Union is not being done on anywhere near the same
scale.
Over the last five years the Soviets have developed at least five
indigenous parallel processing languages for machines ranging from vector
processors such as the PS-2000 to Macro-pipeline architectures to the MARS
asynchronous multiprocessor. These languages use quite a variety of
mechanisms for specifying parallelism, establishing communications between
processes, and implementing data sharing and transfer. None of the
mechanisms are particularly novel conceptually, but an interesting
characteristic of some of the languages is their ability to allow the
programmer to chose which mechanisms he would like to use [Goro84b]. One
of the languages, a vector processing language for the PS-2000 has been in
actual use since 1982 [Kaly84c]. The others are, apparently still in the
developmental phase; we do not know, therefore, what kind of processing
power they will give to the machines they run on.
Soviet activity in this area may be because they see parallelism as a
promising way to get more power from a machine without having to develop
ultra complex hardware circuitry. It is still too early to determine the
relative rates of development of parallel processing software of the US and
the USSR. Given the recent commercial introduction of parallel
architecture machines in the US, it is expected that the rate of software
development for these systems will pick up.
1.c. Database Management Systems
One gets the impression from the most recent literature that more and more
systems are being built on top of database management systems. This
indicates that some systems are fairly widely available (e.g. from
Tsentrprogrammsistem, the centralized software supply house), and that main
memory sizes and disk space are becoming more adequate for these
application (if you consider 200 MByte mainframe drives to be adequate).
It is difficult to evaluate the state of theoretical research, but as far
as applications go, it seems as if DBMS is currently a major growth area.
A fairly comprehensive survey published in 1986 gives a picture of the
situation in 1984. Seven packages enjoyed the distinction of industrial
support, i.e. good documentation, maintenance, and help available. Of
these, two were hierarchical (one a duplication of IMS), and five were
network (one a copy of TOTAL). There were 17 experimental systems listed.
Half of all systems in the software had foreign "analogs." There were 7
relational systems among the experimental systems. SET, BANK-OS, PARMA,
BAYKAL, and SIOD-3-OS use the network model. SETOR-3, SETOR-SM, and
MIKROSETOR use a limited network model (this is TOTAL). DISOD, AIST,
KVANT, SPEKTR, KVANT-M, and MIRIS have a special file organization for
support of indirectly assigned network and hierarchical models. REBD,
PAL'MA, VERA, UNISON, BAZIS, DABU, and BAZA-SM are oriented towards
supporting the relational model but are not relationally complete with
repsect to the DML, so should be called relationally-oriented. Ten of the
24 DBMSs have dictionary-reference aids, 18 have load facilities, 17 have
query generators with non-programmer query languages. To a sufficient
degree all of the DBMSs have asoftware for the DBA. Widely used are: OKA
(a.k.a IMS), INES (also hierarchical), SETOR-3, SETOR-SM, SIOD, BANK-OS,
and BAZA-SM. Having good prospects: DISOD, SET's, etc.
Hence, the Soviets now have a respectable number of hierarchical or
network DBMS products available as several indigenous systems have reached
second or third major versions. Nevertheless, due to the absence of
auxiliary software (e.g. for the DBA and security) and the lack of evidence
of high (industrial) transaction rates, it appears that the US is still
ahead, although the Soviets may be gaining ground. According to one Soviet
interviewed last summer, ADABAS with a Cyrillic front is the most widely
used DBMS there, but we do not have any evidence to back this claim.
The market for relational DBMS in the West has mushroomed in the last few
years, with hundreds of products and millions of copies of micro-computer
database software. The US is definitely ahead here with the gap growing. We
have seen one example of a fairly sophisticated microcomputer DBMS which is
similar to Knowledgeman, and reports of dBase III in the USSR.
The 1986 article indicates these "promising" developments in DBMS since
1980: adaptive (self-organizing) DBMS on the basis of standard components
with system generation; DBMS for holding graphical data and unstructured
data; relationally-complete DBMSs, DBMS with microprogrammed control,
developed for use with database machines; DBMS for operating with DBMSs
in computer networks [Naum86d].
The Soviets are probably about even in the area of informational retrieval
systems. The Soviets and their EE allies are making concerted efforts to
have large, national bibliographical databases. Many millions of references
are now on line with substantial rates of increase. It appears that the
features of the IRS software do not lag behind those in the West. The
biggest difference is that there is much greater access and probably a lot
higher throughput, which may be due largely to superior hardware.
2. Software Environments
2.a. Some stand-alone tools
Debuggers. Some sort of debugger, not always interactive, is available for
nearly all machines. The more advanced debuggers, for ES computers, enable
the programmer to set and delete breakpoints at will, view the contents of
registers and memory locations, change them, etc [Amba84; Ilyu85]. Most of
the debuggers in the USSR are primitive, non-interactive systems. The most
advanced do exhibit many of the features considered standard in the West,
but it does not appear that Soviet debuggers have such functions as
custom tailored debuggers, or some of the more advanced symbolic functions
such as symbol resolution, etc.
Editors. While most of the editors in use have been criticized for being
cumbersome and lacking of sophisticated functions, a recent editor for the
ES computers does have some promising features such as a split screen for
editing multiple files simultaneously [Bezr81; Hein84].
Library Managers. Few of these very important tools have been identified.
Of the major programming environment systems in use in the USSR, only one,
TKP - the Programmer's Toolkit, has a special project development library
to store information about the development process itself [Koto84]. It does not
appear that this system has functions to ensure control of different
developmental versions or modifications as does, for example the UNIX
programmer's workbench.
2.b. Programming Environments
There are very few known software development environments in use in the
Soviet Union. But of these, PROMETEY is the most significant. It is a
system designed for developing code on mainframes for micros, and has been
used to develop a large number of systems (totaling 3 million+ commands)
for a large number of different micros (35). It does not contain a
particularly sophisticated set of tools, but the basics - programming and
specification languages, debuggers, simulators for testing, systems library
- are available [Lipa85b]. Since many of the microcomputers in question
are on-board machines and since the Russian version of Ada, RADA, is being
developed for use with this system, PROMETEY could be particularly suited
to real-time military applications.
Other well developed environments are TKP (The Programmer's Toolkit) and
R-Technology [Koto84; Kupr83; Velb85; Velb86]. While the individual tools
available in these environments are not state of the art, they do support
most phase of software development. Particularly significant are the
features they have for enforcing good programming style and documentation.
These environments are general enough to support, in theory, development of
a wide variety of software. More tools were shown in Moscow at the
Exhibit for the Achievements of the National Economy in 1986. The STEND
enviornment has been developed based on SETL-85 and C and includes library
and language tools plus some capabilities in the areas of production rules
and object-oriented databases. I suspect further research will turn up more
tools.
What has hindered the development of sophisticated programming environments
in the USSR? Although full-function programming environments are not being
used as widely as they might in the US, there are groups of developers who
are very keen on having effective environments for advanced software
development. The Programmer's Workbench of UNIX was developed by such
people. This type of development path - quality users developing tools
that they themselves need primarily for their own use - will result in
greater advances in the state of the art than the path most often taken by
the Soviets. Here the emphasis is on producing the first version of the
system. There are few incentives to carry out maintenance, and hence fewer
for maintenance tools. Likewise for quality assurance tools. Plus the
centralization of the software industry has the effect of stifling the
development of new tool environments when there are already some available
(regardless of how well these can be assimilated or how much real
functionality they provide). Despite the drive for centralization of
software supply, individual institutes tend to be locked into the products
they use, such as DBMS, telecommunications monitors, and tools. So one can
see a few institutes using a set of tools but not much national
distribution. Finally, the size of the software industry still corresponds
to the size of the user communities.
3. Artificial Intelligence
AI has been an active area of research since the early 1970's. Most of the
significant work has been in the areas of knowledge representation and
natural language processing. Several natural language interface systems
have been developed with some success; and one, DILOS, is in use in Austria
[Jako85]. Yet in spite of respectable work in these areas, Soviet work in
expert systems has not been of equal calibre. There do, reportedly, exist
medical diagnostic expert systems, but these are few. More serious than
the low number of expert systems in use, however, is the complete lack of
any expert system building tools such as KEE, or even M.1. In fact, the
only expert system building tool known to be in use is a small, primitive
tool like EXPERT-EASE which is used by E. Kh. Tyugu, the head of AI
research for the MARS computer project [Wolc86c]. That research is
proceeding slowly.
If the literature is to be believed, Soviet systems such as RECH-1
and INTELLEKT have natural language/voice processing capabilities equal to
anything available in the West [Novi85e; Sovi84]. These systems have the
ability process and generate continuous speech. Natural language
interfaces to dbms have been in existence for a few years [Jako85]. This
has been one of the most active areas of AI research. Apparently some of
these systems are actually being used productively in, for example,
economic planning. How wide their conversation domain is and how easily
they can learn new speech is not known.
Expert systems have made any appearance at all only within the last two or
three years. Those that exist are generally diagnostic in nature. Given
the amount of research in knowledge representation (semanitc nets, frames,
scripts, uncertain terms) it is a bit surprising that more expert systems
have not been built. Tyugu (of the Institute of Cybernetics of the
Estonian Academ,y of Sciences and a major AI player), when looking to build
an expert system front end for PRIZ used as a model expert-ease, a
primitive expert system building tool with a knowledge representation
scheme unlike that used by PRIZ [Wolc86c]. A couple of factors are at work
to widen the gap between Soviet and US expert system development. The
first is that the Soviets have not yet should any evidence of any expert
system building tools except for the one mentioned above, while in the US
there already exist a wide selection of tools for building systems of all
sizes and complexity. Secondly, there is enormous financial incentive in
US industry and business to further develop sophisticated expert systems.
The prospects for continued rapid development in this field are very good.
Automatic programming is a phrase with a very imprecise meaning, and
depending on the definition the gap between the US and the USSR is either
widening, or staying about the same. PRIZ is a system which automatically
combines basic program modules from a problem domain description into a
program given a set of input and output variables. Types of automatic
programming that have not been mentioned in the Soviet literature are
interactive systems which query the user to complete lacking information.
If one thinks of automatic programming as equivalent to higher level of 4GL
languages, the the gap is widening because of the efforts being put into
application development tools for the average end user. Many of these
languages are very task specific with high quality screen interfaces.
According to Edward Manukian, an emigre who was in computing before he left
the USSR and then got a philosophy PhD in Canada with a concentration in
AI, some of the Soviet theoretical work is at the state of the art. I am
not in a position to evaluate this work. Manukian is at U. of Maryland and
we may be able to consult him or put him in touch with J. McCarthy.
4. Security
This topic receives so little attention in the Soviet literature that
practically all of the work must be classified. No hacker culture has yet
arisen, mainly because of the absence of personal computers and in
particular, modems. Internal industrial espionage is also not a factor in a
society where results are supposed to be freely shared with anyone who
needs. I am not sure how we will be able to approach this topic.
Breakthrough Technologies (a note)
It is much more difficult to identify these in the USSR without first
having identified them in the West, so once I have more input I may be able
to provide more input here. A basic characteristic of systems software is
the need to preserve upward compatibility, so that it is unlikely we will
see major breakthroughs in any of the standard Soviet computer lines. The
MARS project and other parallel- and supercomputer projects may yield some
breakthroughs.
Protectability (a note)
My basic philosophy here is that the more widespread it is in the West, the
harder it will be to protect. We have seen many examples of acquisitions,
ranging from the IBM 360 operating systems to RSX-11 to various database
management systems. My guess is that the main factor that has kept the
Soviets from acquiring more software has been the lack of suitable machines
on which to run it. For instance, structured programming approaches eat up
large amounts of space, while the Soviets are using slow mainframes with
small disk drives. Software which is optimized for certain hardware
features which the Soviets cannot easily duplicate will be most easily
protected. On the other hand, this may go against commercial desires to
make software more portable, especiallly as more and more machines are
viewed as basic commodity platforms.
Here are some other thoughts about systems software:
All systems software is potentially dual-use.
Systems software is essential, whereas some applications software is not.
Controlling systems software is more in line with preventing technology
transfer, since it denies the adversaries the ability to make things as
opposed to just using things.
Systems software for smaller machines (e.g. MS-DOS) is much easier to
acquire than that for larger machines (e.g. VMS or MVS).
Obviously more thought is needed on this subject.
∂29-Jan-88 1243 CLT nsf
Betty Scott says Keenan from NSF is visiting the department
this quarter (some sort of sabbatical). She didn't know
if you were aware of this and might want to take advantage
of his presence.
∂29-Jan-88 1252 GINSBERG@Sushi.Stanford.EDU read a play on Sunday night?
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 12:52:13 PST
Date: Fri 29 Jan 88 12:47:17-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: read a play on Sunday night?
To: jmc@Sail.Stanford.EDU, clt@Sail.Stanford.EDU
Message-ID: <12370540277.18.GINSBERG@Sushi.Stanford.EDU>
Are either of you interested? Carolyn, I will promise to give you
a small part if you want one and that'll convince you to come ...
Matt
-------
∂29-Jan-88 1533 KEARNS@CS.COLUMBIA.EDU chance meeting
Received: from CS.COLUMBIA.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 15:32:52 PST
Date: Fri 29 Jan 88 18:31:38-EST
From: Steven M. Kearns <KEARNS@CS.COLUMBIA.EDU>
Subject: chance meeting
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12370570196.11.KEARNS@CS.COLUMBIA.EDU>
Hi.
I am a 3rd year PhD at Columbia University. Near the end of October I
was flying to the U of Texas at Austin, out of JFK, I think. I was
attending the Year of Programming Institute on Programs and Proofs.
When I sat down to wait for my plane to board, I was suprised to find,
on the seat next to me, a briefcase with your name on it. This being
New York, I figured that no-one would have left a piece of luggage
unattended on purpose. I tried to find you, even trying to see if you
were taking any of the planes to Stanford, to no avail.
So, I am curious. Did you lose it there?
-steve
(kearns@cs.columbia.edu)
-------
∂29-Jan-88 1715 CWeissman.BSPO@DOCKMASTER.ARPA sOFTWARE COMMITTEE
Received: from DOCKMASTER.ARPA by SAIL.Stanford.EDU with TCP; 29 Jan 88 17:15:04 PST
Posted-Date: 29 Jan 88 20:07 EST
Date: Fri, 29 Jan 88 20:04 EST
From: CWeissman@DOCKMASTER.ARPA
Subject: sOFTWARE COMMITTEE
To: ouster@GINGER.BERKELEY.EDU, CWeissman@DOCKMASTER.ARPA
cc: hearn@RAND-UNIX.ARPA, jmc@SAIL.STANFORD.EDU, blumenthal@A.ISI.EDU,
mchenry%guvax.bitnet@CUNYVM.CUNY.EDU
Message-ID: <880130010414.467265@DOCKMASTER.ARPA>
SOFTWARE SUBCOMMITTEE
Clark Weissman 1/29/88
1. Basic Technology Trends
I agree to much of John's pump priming. Here are some
further observations.
1.1 In the US, the PC has for the first time permitted
mass/volume sales of software pushing substantial fractions
of a million copies. That has permitted rational growth in
the software business to that of hardware and other
product-oriented businesses. Thus, we see the development
of a "software components" business and infrastructure of
"subsystem" suppliers. For major systems, you can buy Font
drivers, dialog boxes, interface tool kits, windows, access
methods, screen managers, backup utilities, etc. This is
possible because of high and LOW level standards -- file
formats (dif, graphics), comm framing (xmodem, kermit,
etc.), GDOS (virtual graphics), net protocols, etc.
Manufacturers of major commercial packages can buy
substantial parts of their end product and become
integration contractors. It permits more rapid
commercialization of ideas and compression of
manufacturing. It also makes it harder for foreign
companies to compete.
1.2 Proprietary software is shifting from major products to
the infrastructure products described above. Post Script is
but one such example. Digital Research Inc. GEMs is
another, Bootroms and other special interfaces are the key
"uniques" of modern software.
1.3 Tools for software development and operation are in
renaissance, and damn good. For $100.00 you can buy any
modern language development system with editor, compiler,
linker, loader, symbolic debugger, memory dump, and library
of valuable source code software components. This is both a
business itself -- building and selling software tools --
and part of the infrastructure feeding other software
developments.
1.4 Distributed processing is a computer trend with major
software implications in networking and communication
described in another committee. Here I only wish to note
the impact it is having on software trends.
a. Easy connectivity and data interchange --
user/mfg/govt. b. Document and report construction from
dispersed sources; this
report for example. c. New system software to
support distributed architecture; e.g.,
database machines, file server, user name/address
server, print
server, etc. d. Security sensitivity and
integrity services.
2. Breakthru Possibilities
What is a breakthru? DARPA likes decimal order of
magnitude better: performance, cost reduction, error
reduction, user productivity, etc. I'll use that definition
for my speculations.
2.1 Software development from proprietary packages per 1.1
above. We are in the midst of that breakthru now. And it
will escalate with better tools feeding better components
feeding better tools feeding ... .
2.2 Program verification -- proof of functional correctness
of code -- has been slowly growing in accomplishment.
Today, we can prove correspondence of formal specifications
to formal requirements (policy model) for 100,000 lines of
spec. We are able to prove correspondence of code to spec
for 10,000 lines of code. The tools are emerging from hand
craft to production quality. Estimated "breakthru" per
definition: 1993-95.
2.3 Formal design -- software design based upon rigorous
specification of the functionality. In concert with 2.2,
there is an increasing focus on the design of software
systems and components with more formal, mathematical
precision. Relational calculus, object-oriented design,
well specified standards and interfaces, strong typed
languages -- ADA, Modula, Pascal. This trend is leading to
increased productivity by reducing the labor intensive
post-design testing phase, and the life-cycle maintenance
phase. Next 10 years will see more than 50% of software so
produced.
2.4 User encryption services -- for integrity,
security/privacy, authentication -- are just emerging from
Govt and university R&D. I predict widespread use in nets
and for software distribution in the next 10 years.
Technology is not the pacing item, govt control/policy and
technology integration into evolving nets and distribution
channels are retardants.
3. National Players
The US is certainly the biggest player, and by current
standards, the best as well in terms of innovation, and
quality. However, if breakthrus 2.2 and 2.3 come to pass,
the USSR has a greater pool of mathematicians and
formalists, and a culture of support for rigorous
expression, which could let them become a significant
player in the next century. They have been strong in theory
but weak in practice. In the next 10 years their practice
will improve by various means, permitting their theoretical
skills to blossom and pose a significant capability.
European countries also have a strong theoretical
tradition, and they have access to practical machine
technology as well. We are beginning to see them as a force
in the software market. Many superb software packages were
imported to the US from overseas. More can be expected.
Software is labor intensive, therefore, our biggest
competition will come from the largest populated countries
when those countries attain the computer hardware. The PC
is now making inroads in India and China. How long before
we see their impact in the marketplace?
4. Protectability
True, software is easy to steal, copy, plagerize thus
making it hard to protect. However, it is also hidden,
obscure, poorly documented, and fragile which can reduce
the speed of "diffusion." Manufacturers have learned this
by charging order of magnitude more for source code
licenses, and seldom sell their coding specs. This is a
form of encyption. Therefore, why not institutionalize the
technique?
4.1 Protectability by control of maintenance and updates is
practical for large bodies of code -- system and
application code over 100,000 lines. Keep the source code
(never sell or deliver to the end-user). Sell only
maintenance services by the US-controlled mfg or licensed
service contractor. Given world-wide nets, this can be
provided conveniently in the future ala today's BBS
(bulletin board systems). Reverse engineering gets that
version, but not subsequent versions nor bug fixes.
Reengineering each version will be an excellent way to
bankrupt the thief.
4.2 Protection by encryption is a viable option. Copy
protected disks have proven imperfect against all but the
dumb, and they have alienated the buyer. Popular wisdom
then, is the scheme has failed. I'm less sure. I think the
current scheme is poor, but that modern and near future
encryption schemes are better. Also, the market needs to
better appreciate their own benefits with "trusted"
distribution, e.g., integral data and code unmodified by
accident or intent in transit from "store-to-door." If
telemarketing, videotext, COMPUSERVE channels thrive, such
technology will be indispensible for a thriving marketplace
of electronic exchange of assets.
Public key and DoD grade encryption will be in wide use by
the mid 1990's, particularly on nets and PCs. Given the
base encryption hardware, high quality software protection
will be possible.
5. Security
There is lots to say on this subject. Some of the
technologies are noted above in software verification and
encryption. I will address myself to two areas; software
used for protecting US and friendly assets, and software
used to "unprotect" unfriendly assets. Since this can get
classified, I will just prick your interests.
5.1 Trusted Computing Base, TCB, is the DoD terminology for
the hardware, software, human, and facility assets used to
protect classified information systems. Given a secure
facility, cleared personnel, and a multidomain cpu,
security provided by the TCB resolves to trusted software.
DoD 5200.28-STD defines the criteria for evaluating
trustworthiness of software, resolving such trust to seven
levels -- A1 (highest), B3, B2, B1, C2, C1, D (no trust).
Trusted software controls the machine and the untrusted
software. When properly built, trusted software would be
about 1% of the total software base (10,000 - 20,000 HOL
lines of code). A1 software is formally developed with
proven specs and the finest traditions of software
lifecycle engineering. C1 software is well tested analogous
to best commercial practice. B1 through A1 TCB obeys
military classification rules, whereas C1 and C2 TCB
follows a need to know set of access controls.
Secure TCBs software must be protected from diffusion,
loss, and theft as it could aid and strengthen foreign
military operations. It must also be protected from
unauthorized modification, that could corrupt its integrity
and deny service to our DoD systems.
5.2 Since software is easily corrupted, one must be
concerned with intentionally "bugged" software (pun
intended), particularly, foreign products and components.
As the software infrastructure grows, it becomes more
difficult to identify the "pedigree" and origin of the
coded components. That is a significant security problem
for military and possibly significant industrial software.
It may be an important "means" for protecting against
software technology diffusion and theft. "Caveat Emptor,"
let the thief beware! "Attack software" has been tried as
a means to protect software from theft. Such software, if
not legally obtained and operated, would attack the host
system, such as erasing a file or zeroing a hard disk. It
has not proven successful in the marketplace for fear from
legit users that an accident or operational lapse would
cause the loss of their valuable property. It may, however,
see a better future in export control!
∂30-Jan-88 1140 mcvax!litp!queinnec@uunet.UU.NET IWoLES (copyright release)
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Jan 88 11:39:59 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA18275; Sat, 30 Jan 88 14:40:09 EST
Received: by mcvax.cwi.nl; Sat, 30 Jan 88 12:35:55 +0100 (MET)
Received: by inria.inria.fr; Fri, 29 Jan 88 20:14:02 +0100 (MET)
Received: by litp.unip6-7.fr (5.51/5.17)
id AA19876; Fri, 29 Jan 88 12:28:02 +0100
Date: 29 Jan 1988 12:13-EST
From: mcvax!inria.inria.fr!queinnec@uunet.UU.NET
Subject: IWoLES (copyright release)
To: mathis@a.ISI.EDU, jmc@sail.stanford.edu,
ito%aoba.tohoku.junet@uunet.UU.NET, masinter.pa@xerox.com,
bobrow.pa@xerox.com, inria!inria.inria.fr!pc@uunet.UU.NET,
willc%tekchips%Tektronix.CSNET@RELAY.CS.NET,
ukc!hlh!bath63!ma_jap@uunet.UU.NET, kmp@stony-brook.scrc.symbolics.com,
jmh@next.com, inria!inria.inria.fr!devin@uunet.UU.NET,
rpg@sail.stanford.edu, inria!inria.inria.fr!kahn@uunet.UU.NET,
dussud%jenner%ti-csl.csnet@RELAY.CS.NET, crcge1!sanson@uunet.UU.NET
Cc: inria!inria.inria.fr!queinnec@uunet.UU.NET
Message-Id: <570453236/queinnec@litp>
AFCET has received some request to let publish the proceedings
of IWoLES. We cannot do that if you do not sign a copyright
release in favor of AFCET. To that goal, forms have been sent
to you. Can you answer us quickly. Thank you and
Best regards
Christian Queinnec.
∂30-Jan-88 1147 mcvax!litp!queinnec@uunet.UU.NET IWoLES
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Jan 88 11:47:00 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA18687; Sat, 30 Jan 88 14:47:11 EST
Received: by mcvax.cwi.nl; Sat, 30 Jan 88 14:29:42 +0100 (MET)
Received: by inria.inria.fr; Fri, 29 Jan 88 20:06:05 +0100 (MET)
Received: by litp.unip6-7.fr (5.51/5.17)
id AA19688; Fri, 29 Jan 88 12:13:30 +0100
Date: 29 Jan 1988 12:05-EST
From: mcvax!inria.inria.fr!queinnec@uunet.UU.NET
Subject: IWoLES
To: jmc@sail.stanford.edu, jmh@next.com,
inria!inria.inria.fr!kahn@uunet.UU.NET
Cc: inria!inria.inria.fr!devin@uunet.UU.NET, crcge1!sanson@uunet.UU.NET,
inria!inria.inria.fr!queinnec@uunet.UU.NET
Message-Id: <570452760/queinnec@litp>
I cannot wait for your three-page paper more than February, 3th.
Can you send them to me before ? Many thanks
Christian Queinnec
∂30-Jan-88 1633 GINSBERG@Sushi.Stanford.EDU play tomorrow?
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 16:33:49 PST
Date: Sat 30 Jan 88 16:28:56-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: play tomorrow?
To: jmc@Sail.Stanford.EDU
Message-ID: <12370842770.19.GINSBERG@Sushi.Stanford.EDU>
Can you let me know when you decide? I need to photocopy a play,
and which one it will be depends on how many people I'm getting ...
[Meanwhile, I seem to be making some progress convincing Carolyn
to join us some time ...]
Thanks.
Matt
-------
∂30-Jan-88 1740 RPG Wednesday
To: IGS@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU,
CLT@SAIL.Stanford.EDU
Wednesday at 6 pm at Lucid with food provided for the DARPA meeting: Shall
you all make it?
-rpg-
∂30-Jan-88 1830 ILAN@Score.Stanford.EDU Apparently Berliner doesn't like flames
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 18:30:27 PST
Date: Sat 30 Jan 88 18:25:38-PST
From: Ilan Vardi <ILAN@Score.Stanford.EDU>
Subject: Apparently Berliner doesn't like flames
To: jmc@Sail.Stanford.EDU
cc: ilan@Score.Stanford.EDU
Message-ID: <12370864015.11.ILAN@Score.Stanford.EDU>
Though he seems more than ready to do it himself (from rec.games.chess)
Article 757 of rec.games.chess:
Path: labrea!rutgers!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!berliner
From: berliner@K.GP.CS.CMU.EDU (Hans Berliner)
Newsgroups: rec.games.chess
Subject: Re: 4th round of Candidates
Message-ID: <765@PT.CS.CMU.EDU>
Date: 29 Jan 88 19:48:14 GMT
References: <3939@husc6.harvard.edu>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 11
Summary: Inconsistency in Report
Firstly, I want to also express my gratitude to David Frey for his
postings which are extremely valuable, especially so since Ken
Thompson is now in Australia. These "factual" reports stand out
well when compared to the wild opinions of certain regulars on this
net who never ever bother to state their qualifications to pontificate
on whatever subject they happen to have latched on to today.
Unfortunately, the retyping of the AP newsrelease must have produced an
error. In the round 3 report Vaganian leads Portisch 2-1; at the end
of 4 rounds he is behind 2.5-1.5 . Impossible!. David, could you please
be so kind.
-------
∂31-Jan-88 0751 RPG
∂30-Jan-88 1753 JMC re: Wednesday
To: RPG@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU,
CLT@SAIL.Stanford.EDU
[In reply to message from RPG rcvd 30-Jan-88 17:40-PT.]
Carolyn and I would prefer to have the "business meeting" 5pm to
(say) 7pm with eating optional. I'd probably stay for it, and
she probably wouldn't. Is this feasible?
Yes, it's feasible, assuming Boesch can make it by 5.
-rpg-
∂31-Jan-88 1149 JSW Gang-of-Four
To: JMC, CLT
So far I've opened Gang-of-Four accounts for anyone that asked, but
now that the department is moving toward Unix computing there may be
a temptation for people to avoid CSD-CF charges by using our machine.
Do you have any opinions on who should or should not get accounts and
what they may be used for?
∂31-Jan-88 1207 edsel!jlz@labrea.Stanford.EDU Paris hotel
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 88 12:07:31 PST
Received: by labrea.Stanford.EDU; Sun, 31 Jan 88 12:07:46 PST
Received: from sunvalleymall.lucid.com by edsel id AA09386g; Sun, 31 Jan 88 11:59:38 PST
Received: by sunvalleymall id AA07094g; Sun, 31 Jan 88 12:03:49 PST
Date: Sun, 31 Jan 88 12:03:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8801312003.AA07094@sunvalleymall.lucid.com>
To: JMC@sail.stanford.edu
Cc: edsel!jlz@labrea.Stanford.EDU
In-Reply-To: John McCarthy's message of 30 Jan 88 1756 PST <8801310743.AA07288@edsel.lucid.com>
Subject: Paris hotel
Thanks for getting back to me.
In case you don't have the number of the Napoleon:
47.66.02.02, Telex 640609
---jan---
∂31-Jan-88 1449 JSW Reminder: Symbolics Multiprocessor meeting
To: "@QLISP1.DIS[1,JSW]"@SAIL.Stanford.EDU
The meeting with Carl White from Symbolics, to present their
new multiprocessor, is this Monday, February 1, at 2:30 p.m.
in MJH 252.
∂31-Jan-88 1742 CLT Gang-of-Four
To: JSW
CC: JMC
I would favor in general limiting them to
people associated with our group
people doing qlisp applications
people with a genuine need for Alliant type parallel processing
with non-qlisp users getting lowest (or no) priority when there
is a qlisp crunch. I think we should also ask non-qlisp users not to
make heavy use of cycles expect when the the machine is not
otherwise in use.
∂01-Feb-88 0815 RPG Arpa Visit
To: JMC@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
IGS@SAIL.Stanford.EDU
Wednesday at 5:00pm at Lucid is agreed by Boesch.
-rpg-
∂01-Feb-88 0900 JMC
bass, jim gray, yao, wilson, angelo
∂01-Feb-88 1042 SINGH@Sierra.Stanford.EDU re: Passing of `Frontier Gandhi'
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 10:42:00 PST
Date: Mon 1 Feb 88 10:40:39-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: re: Passing of `Frontier Gandhi'
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@sail.stanford.edu>" of Sat 30 Jan 88 18:52:00-PST
Message-ID: <12371303657.28.SINGH@Sierra.Stanford.EDU>
I do not know the periods when he was incarcerated
but I gather that the Pakistani government was highly displeased
with him on a number of occasions. He had a tendency to speak
his mind and mobilize his people against the (numerous) excesses
of successive Pakistani governments. Many Pakistanis therefore
think of him as a `traitor' to the nation!
Sorry for the delay in answering - Sierra has been
dead for most of the weekend.
Inder
-------
∂01-Feb-88 1345 helen@psych.Stanford.EDU MY generation
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 13:45:27 PST
Received: by psych.Stanford.EDU (3.2/4.7); Mon, 1 Feb 88 13:44:18 PST
Date: Mon, 1 Feb 88 13:44:18 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: MY generation
Cc: helen@psych.Stanford.EDU
Hi there,
Since we didn't get to that one last time, and it seems to be
"in the news" once more, why don't we make it the topic of our
next luncheon meeting? If interested, just suggest a time.
(Actually this week is bad, but any time thereafter...)
-helen
∂01-Feb-88 1416 helen@psych.Stanford.EDU re: MY generation
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 14:16:03 PST
Received: by psych.Stanford.EDU (3.2/4.7); Mon, 1 Feb 88 14:14:54 PST
Date: Mon, 1 Feb 88 14:14:54 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: MY generation
Wednesday, Feb. 10 sounds just fine. Noon in front also fine.
See you then and there!
-helen
∂01-Feb-88 1615 edsel!arg@labrea.Stanford.EDU Qlisp DARPA meeting Wednesday night
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 16:14:54 PST
Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 16:15:05 PST
Received: from bhopal.lucid.com by edsel id AA13582g; Mon, 1 Feb 88 16:01:21 PST
Received: by bhopal id AA06706g; Mon, 1 Feb 88 16:05:26 PST
Date: Mon, 1 Feb 88 16:05:26 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802020005.AA06706@bhopal.lucid.com>
To: JMC@sail.Stanford.EDU, CLT@sail.Stanford.EDU, IGS@sail.Stanford.EDU,
jsw@sail.Stanford.EDU
Cc: rpg@sail.Stanford.EDU, edsel!carol@labrea.Stanford.EDU,
edsel!tony@labrea.Stanford.EDU
Subject: Qlisp DARPA meeting Wednesday night
Here's a tentative agenda for the meeting Wednesday evening:
5pm - 6pm: Lucid Qlisp work:
1. Qlisp overview - rpg
2. Status of current Qlisp implementation - arg
3. Proposed Qlisp work for the next 18 months - rpg
6pm - 7pm: Stanford Qlisp work:
1. What's been done so far
2. What's going to be done
We'll have a viewgraph projector setup. Probably after the presentation
some subset of people will go out to eat dinner.
Ron
∂01-Feb-88 1639 RICHARDSON@Score.Stanford.EDU Visiting Committee Agenda
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 16:38:56 PST
Date: Mon 1 Feb 88 16:33:44-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Visiting Committee Agenda
To: eustis@Sierra.Stanford.EDU, levinthal@Sierra.Stanford.EDU,
tajnai@Score.Stanford.EDU, reges@Score.Stanford.EDU,
buchanan@SUMEX-AIM.Stanford.EDU, genesereth@SUMEX-AIM.Stanford.EDU,
phy@Sail.Stanford.EDU, zm@Sail.Stanford.EDU, rwf@Sail.Stanford.EDU,
goldberg@Score.Stanford.EDU, pratt@Navajo.Stanford.EDU,
mayr@Score.Stanford.EDU, fersiger@Score.Stanford.EDU,
jcm@Navajo.Stanford.EDU, ullman@Score.Stanford.EDU,
guibas@Navajo.Stanford.EDU, latombe@Whitney.Stanford.EDU,
binford@Whitney.Stanford.EDU, jmc@Sail.Stanford.EDU,
shoham@Score.Stanford.EDU, ok@Coyote.Stanford.EDU,
wheaton@athena.Stanford.EDU
Message-ID: <12371367934.41.RICHARDSON@Score.Stanford.EDU>
My apologies for sending a scribe version of the agenda to most of you. A
hard copy of the agenda will be available.
Heidi
-------
∂01-Feb-88 1725 Qlisp-mailer meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 17:21:24 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08037; Mon, 1 Feb 88 17:21:36 pst
Date: Mon, 1 Feb 88 17:21:36 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802020121.AA08037@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: meeting
will be this wednesday at noon, as usual. Unusually, it will be in
MJH146 (the swank conference room on the first floor).
On the agenda will be a discussion of Arkady's GCD implementation as
well as any current business that may present itself.
CUthere
Igor
∂01-Feb-88 2049 rivin@Gang-of-Four.Stanford.EDU meeting at LUCID (on wednesday)
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 20:49:47 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08355; Mon, 1 Feb 88 20:49:59 pst
Date: Mon, 1 Feb 88 20:49:59 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802020449.AA08355@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: meeting at LUCID (on wednesday)
Would it be possible for Joe to come along, you think?
∂01-Feb-88 2233 RDZ@Score.Stanford.EDU [David Chapman <ZVONA@AI.AI.MIT.EDU>: Segreyev]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 22:33:53 PST
Date: Mon 1 Feb 88 22:29:02-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: [David Chapman <ZVONA@AI.AI.MIT.EDU>: Segreyev]
To: jmc@Sail.Stanford.EDU
Message-ID: <12371432614.37.RDZ@Score.Stanford.EDU>
Do you happen to know the gentleman of whom this message speaks?
Ramin
---------------
Return-Path: <@AI.AI.MIT.EDU:ZVONA@AI.AI.MIT.EDU>
Received: from AI.AI.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 1 Feb 88 14:43:17-PST
Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 FEB 88 17:35:04 EST
Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Mon 1 Feb 88 17:32:45-EST
Date: Mon, 1 Feb 88 17:30:43 EST
From: David Chapman <ZVONA@AI.AI.MIT.EDU>
Subject: Segreyev
To: AGRE@AI.AI.MIT.EDU, BUG-SDL@OZ.AI.MIT.EDU
Message-ID: <319616.880201.ZVONA@AI.AI.MIT.EDU>
[I spent some time talking to Victor Segreyev, who is one of the
honchos in AI in Russia. Phil asked me to ask him about Vygotsky.]
Extremely interesting, but very hard to summarize. But re your
question, some of the Soviet AI people are very hip indeed. The
Vygotskian tradition is a major influence, and they understand the
connections between that tradition (especially as represented in
Bakhtin, whom I've been meaning to read) and conversation analysis.
(I have the English abstract of a paper in Russian about this; the
English cites are to all the right things.) AI in the USSR apparently
participates in the general Continental dissolution of disciplinary
boundaries; Segreyev, for example, wears at least three hats: as an
international policy analyst, as an AI guy, and as a literary critic.
(He's big on Thucidides.) It sounds like an awful lot of what they do
is severely bogus, but that some of it is also very good. They have
severe funding problems, because they are under pressure both from
computer scientists and other technoids, who (as here) think AI is
bogus, and from their philosophical Establishmentradition, which of
course is much more powerful there than here, and which mostly holds
that Marxism-Lenninism is incompatible with Man being a machine.
-------
∂01-Feb-88 2243 rivin@Gang-of-Four.Stanford.EDU extension
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 22:43:03 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08560; Mon, 1 Feb 88 22:43:14 pst
Date: Mon, 1 Feb 88 22:43:14 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802020643.AA08560@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: extension
Betty Scott tells me that John Pucci has called her and apologized for
the delay approving the no-cost extension. He said it should come
through in ``a few days''
∂02-Feb-88 0052 RFC Prancing Pony Bill
Prancing Pony bill of JMC John McCarthy 2 February 1988
Previous Balance 8.04
Monthly Interest at 1.0% 0.08
Current Charges 4.00 (bicycle lockers)
-------
TOTAL AMOUNT DUE 12.12
PAYMENT DELIVERY LOCATION: CSD Receptionist.
Make checks payable to: STANFORD UNIVERSITY.
Please deliver payments to the Computer Science Dept receptionist, Jacks Hall.
To ensure proper crediting, please include your PONY ACCOUNT NAME on your check.
Note: The recording of a payment takes up to three weeks after the payment is
made, but never beyond the next billing date. Please allow for this delay.
Bills are payable upon presentation. Interest of 1.0% per month will be
charged on balances remaining unpaid 25 days after bill date above.
An account with a credit balance earns interest of .33% per month,
based on the average daily balance.
You haven't paid your Pony bill since 11/87.
Accounts with balances remaining unpaid for more than 55 days are
considered delinquent and are subject to reduction of credit limit.
Please pay your bill and keep your account current.
∂02-Feb-88 0902 DEK
∂01-Feb-88 2310 JMC Gosper
has been laid off by Symbolics, although they offer him a job
in the Macsyma group if he'll move back East. He wants to stay
here, and now seems interested in a permanent Research Associate
position. I said I would be glad to PI for him if he would
write a proposal. Actually you probably know much more about
the mathematical interest of his work than I do, and I hope
you would be interested in helping get it started. Anyway
he's coming in Friday at 4pm. Is that convenient for you?
*** John, I strongly support the idea of having Gosper here as
a Senior Research Associate, and I will be glad to help (up until
December 31, 1989!). I think I'm free on Friday at 4; will put it
on my calendar.
∂02-Feb-88 0922 MPS Sequent Computer
Don McAlister (408 436-8448) called regarding an
invitation sent to you for a seminar they are having tomorrow
and also he would like to make an appointment to see you this
week if he could.
Pat
∂02-Feb-88 0932 BRINK@Sushi.Stanford.EDU Meeting
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 09:32:42 PST
Date: Tue 2 Feb 88 09:27:34-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: Meeting
To: jmc@Sail.Stanford.EDU
cc: VAL@Sail.Stanford.EDU
Message-ID: <12371552496.21.BRINK@Sushi.Stanford.EDU>
I understand you would like to meet with me. I need to see the cashier about a
reimbursement, so late in the day today or Thursday makes sense. I'll check my
mail again before 1, and after my last meeting, about 2:45.
..Ed
-------
∂02-Feb-88 1045 DEK memo to Nils
To: RWF@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU,
VRP@SAIL.Stanford.EDU, LG@SAIL.Stanford.EDU,
ullman@SCORE.Stanford.EDU, manna@SCORE.Stanford.EDU
Having received no negative feedback on the draft of the memo I sent
you for proofreading on Friday, I assume it's OK to send it to Nils.
Therefore I'll do so early this afternoon (unless one of you tells
me not to, before then). OK?
∂02-Feb-88 1117 GINSBERG@Sushi.Stanford.EDU Schwartz visit
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 11:17:31 PST
Date: Tue 2 Feb 88 11:12:03-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: Schwartz visit
To: ginsberg@Sushi.Stanford.EDU, nilsson@Score.Stanford.EDU,
genesereth@Score.Stanford.EDU, latombe@Coyote.Stanford.EDU
cc: val@Sail.Stanford.EDU, jmc@Sail.Stanford.EDU
Message-ID: <12371571515.31.GINSBERG@Sushi.Stanford.EDU>
As we discussed, two of the presentations (architectures and computation)
will involve showing Schwartz a bunch of overviews and then letting him
choose one to hear more about. Does it make sense to make all of the
single-slide overviews have the same format? Arguments for are that
it will make it easier for Jack to absorb the information, and give us
something compact to give him to take away. The argument against is
that he'll be tired, and the repetition will force the presenters to
be even more sparkling and charismatic than usual.
Anyway, if people think this is a good idea, I'll be happy to do the
work. I guess what I'd need for each project would be:
title
personnel
contribution
application area (?)
funder
funding level
And, of course, anything I've forgotten from the above list.
Matt
-------
∂02-Feb-88 1412 celniker@cadlab2.MIT.EDU
Received: from ATHENA (ATHENA.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Feb 88 14:12:39 PST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA24186; Tue, 2 Feb 88 17:07:45 EST
Message-Id: <8802022207.AA24186@ATHENA.MIT.EDU>
Received: by cadlab2 id AA01104g; Tue, 2 Feb 88 17:05:54 EST
Date: Tue, 2 Feb 88 17:05:54 EST
From: George celniker <celniker@cadlab2.MIT.EDU>
To: goodman%arizmis@athena.mit.edu, duane.adams%c.cs.cmu.edu@athena.mit.edu,
dongarra%anl-mcs.arpa@athena.mit.edu, gannon%dec-hudson@athena.mit.edu,
hearn%rand.org@athena.mit.edu, jlh%sierra.stanford.edu@athena.mit.edu,
jmc%sail.stanford.edu@athena.mit.edu, mchenry%guvax@athena.mit.edu,
ouster%ginger.berkeley.edu@athena.mit.edu,
cweissman%dockmaster.arpa@athena.mit.edu,
blumenthal%a.isi.edu@athena.mit.edu, gossard@ATHENA.MIT.EDU,
celniker@ATHENA.MIT.EDU
To: members of the committee to study international developments in computer
science and technology.
David Gossard has changed his mailing address to:
gossard@cadlab2.mit.edu
Please send a trial mail message to this new address so that we can verify
that our local mailer is working properly. Thanks for your cooperation.
∂02-Feb-88 1431 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
COMPILING CIRCUMSCRIPTIVE THEORIES INTO LOGIC PROGRAMS
Vladimir Lifschitz
Stanford University
Friday, February 5, 3:15pm
MJH 301
In this work, joint with Michael Gelfond, we study the possibility of
reducing some special cases of circumscription to logic programming. The
description of a given circumscriptive theory T can be sometimes transformed
into a logic program P, so that, by running P, we can determine whether a
given ground literal is a theorem of T. The method is applicable, in
particular, to some formalizations of tree-structured inheritance systems
with exceptions.
∂02-Feb-88 1507 JSW Symbolics Multiprocessor
To: "@QLISP1.DIS[1,JSW]"@SAIL.Stanford.EDU
Carl White called to say that Howard Shrobe from Symbolics will be
visiting the area next week. He's invited anyone of us who wants to
talk with him to dinner on either February 9 or 10 (Tuesday or
Wednesday, we can pick the date). Please let me know if you are
interested and which date you prefer. (My own preference is for
the 9th, because the Computer Forum is on the 10th and 11th.)
∂02-Feb-88 1533 MPS phone
Professor Nicholas Findler of Arizona State would
like you to call. 602 965-5934. He would not
enlighten me as to the subject matter.
pat
∂02-Feb-88 1644 RICE@SUMEX-AIM.Stanford.EDU re: A big thankyou...
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 16:41:13 PST
Date: Tue, 2 Feb 88 16:40:19 PST
From: James Rice <Rice@SUMEX-AIM.Stanford.EDU>
Subject: re: A big thankyou...
To: JMC@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri, 29 Jan 88 14:30:00 PST
Message-ID: <12371631276.66.RICE@SUMEX-AIM.Stanford.EDU>
Hello,
Sorry about the delay in replying. I'll send you a copy just as
soon as they've got our Xerox fixed here. I doubt it'd be of
much interest to you though, since it's largely about way ||AI/
symbolic programming is hard, and you know that already. It's
aimed at the Cray boys, who may well not have thought beyond
finite element analysis and their vectorising Fortran compilers.
Rice.
-------
∂02-Feb-88 1701 VAL nonhyphenating "non"
Matt, in his comments on my draft introduction, says that "non" is apparently
never hyphenated, and suggests, in particular, that I write "nonmonotonic".
Do we want to do that? If yes, do we want to change that in your papers too?
∂02-Feb-88 1854 VAL
Which of your files contains the latest version of the CBCL paper?
∂02-Feb-88 2025 VAL draft introduction
I've received lots of comments and suggestions, and I keep editing (hopefully
improving) it all the time. Tell me when you decide to look at it again, and
I'll give you the latest version.
∂03-Feb-88 1054 ILAN@Score.Stanford.EDU [Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>: [MLB@WHITE.SWW.Symbolics.COM: [ILAN@Score.Stanford.EDU: Re: questions o
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 10:54:25 PST
Date: Wed 3 Feb 88 10:49:33-PST
From: Ilan Vardi <ILAN@Score.Stanford.EDU>
Subject: [Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>: [MLB@WHITE.SWW.Symbolics.COM: [ILAN@Score.Stanford.EDU: Re: questions of mathematical style]]]
To: jmc@Sail.Stanford.EDU
Message-ID: <12371829563.47.ILAN@Score.Stanford.EDU>
This is where I got it from, I guess it's Le Brun who knoweth. RWG seems
to indicate ``Melzak I'' as the reference
---------------
Return-Path: <@ELEPHANT-BUTTE.SCRC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM>
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SCORE.STANFORD.EDU with TCP; Mon 1 Feb 88 23:18:43-PST
Received: from RUSSIAN.SPA.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260289; Tue 2-Feb-88 01:56:18 EST
Received: from TSUNAMI.SPA.Symbolics.COM by RUSSIAN.SPA.Symbolics.COM via CHAOS with CHAOS-MAIL id 55608; Mon 1-Feb-88 22:56:38 PST
Date: Mon, 1 Feb 88 22:56 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: [MLB@WHITE.SWW.Symbolics.COM: [ILAN@Score.Stanford.EDU: Re: questions of mathematical style]]
To: "ILAN@Score.Stanford.EDU"@ELEPHANT-BUTTE.SCRC.Symbolics.COM
Message-ID: <880201225638.0.RWG@TSUNAMI.SPA.Symbolics.COM>
Date: Mon, 1 Feb 88 09:55 PST
From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>
Date: Sat, 30 Jan 88 00:04 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Marc: I think what he wants is G. Boole's quote from the beginning of Melzak I,
warning that, in mathematical education, a premature emphasis on the abstract
at the expense of the concrete vitiates "a masculine vigour of intellect".
Can you denoise this for us?
"Of the many forms of false culture, a premature converse with abstractions is
perhaps the most likely to prove fatal to the growth of a masculine vigour of
intellect." -- G. Boole
"My MATHEMATICS is THROBBING like JELLY on a PLATE!" -- Z. Pinhead
-------
∂03-Feb-88 1206 Qlisp-mailer Carolyn's questions about fib
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 12:06:15 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02063; Wed, 3 Feb 88 12:06:23 pst
Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 12:06:26 PST
Received: from bhopal.lucid.com by edsel id AA19082g; Tue, 2 Feb 88 18:29:21 PST
Received: by bhopal id AA08988g; Tue, 2 Feb 88 18:33:37 PST
Date: Tue, 2 Feb 88 18:33:37 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802030233.AA08988@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Carolyn's questions about fib
Carolyn asked three questions about the experiments Dick & I did with fib.
Here are some answers/questions:
1) I just tried out a parallel fib that when the depth cutoff is reached
calls a serial fib (qsfib) and as would be expected it was lots faster
than a parallel fib that keeps passing a depth argument around. For
(fib 25) the parallel/serial version was about 1.5 times faster than
the full parallel version or a speedup of from 2.6 to 3.8 compared to
the serial version. Clearly the time taken to evaluate the QLET
predicate cannot be ignored, especially if an extra function argument
needs to be passed.
2) I must have missed John's claims for factors of 100 or 1000 - could
you repeat them?
3) I tried changing the qempty predicate to a test based on the queue size
and that was faster, but still showed great variability. Checking for
at least two processes in the run queue gave the best results, which
were almost as good as the best depth setting --- but because of the
variability, it also sometimes ran worse than the worst depth setting.
Increasing the required length of the run queue gave slower times,
presumably because it gave greater opportunity for scheduling (fib n)
for smaller values of n. I think the n-queue model is better behaved
in this sort of situation since the processors are more decoupled.
Given a chance to wave my hands I think I can explain why, but I don't
want to type a lot now.
Ron
∂03-Feb-88 1333 Qlisp-mailer factors of 100-1000
To: qlisp@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Re point 2) of Ron's msg. John has on many occasions made the
claim that it was not going to be necessary to fine tune the
parameters that control the spawning of processes since if
the parameter is within a factor of 100 or 1000 of the optimum
we will still get good results. Maybe I have misinterpreted
this claim, and maybe qfib is not a good sample but the graphs
in Dick and Ron's paper certainly don't support this claim.
∂03-Feb-88 1343 Mailer re: More mathematical style
Received: from KL.SRI.COM by SAIL.Stanford.EDU with TCP; 3 Feb 88 13:43:39 PST
Date: Wed 3 Feb 88 13:43:50-PST
From: Richard Steinberger <STEINBERGER@KL.SRI.COM>
Subject: re: More mathematical style
To: JMC@SAIL.STANFORD.EDU
cc: ILAN@SCORE.STANFORD.EDU, su-etc@SAIL.STANFORD.EDU, STEINBERGER@KL.SRI.COM
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Wed 3 Feb 88 10:23:00-PST
Message-ID: <12371861291.38.STEINBERGER@KL.SRI.COM>
John, Oh John,
Is it really necessary to insult people with whom you disagree?
Especially without asking for a fuller explanation of the "offending"
idea. Clearly you seem to think it is.
For those who may still be interested, I was, somewhat facetiously,
wondering what might have led G. Boole to assume that "vigour of
intellect" was a masculine attribute? Does this seem like an attack on the
author? Well, excuse me. Must be one of my feminine weaknesses!
-Ric Steinberger
-------
∂03-Feb-88 1545 PHY vita
John, Zohar has asked me to get a copy of Nati Linial's vita which you
have. Please let me have a copy. Thanks, Phyllis
∂03-Feb-88 1655 Mailer re: United Nations & Israel
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 16:55:26 PST
Date: Wed 3 Feb 88 16:50:09-PST
From: Liam Peyton <PEYTON@Sushi.Stanford.EDU>
Subject: re: United Nations & Israel
To: JMC@Sail.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 2 Feb 88 17:42:00-PST
Message-ID: <12371895210.35.PEYTON@Sushi.Stanford.EDU>
Policy? I was reacting to what I perceived as excessive and unnecessary
violence that would serve only to irritate an open wound and promote
continuing hatred for years to come. I understand that quelling riots
is not pretty - I would expect beatings of demonstrators and lots of
arrests. Bullets against stone throwers, entering houses indiscriminately
to inflict beatings, deliberately breaking hands etc. do not fit into
this picture.
Since you asked, though, let me take a crack at armchair policy making.
If Israel wants the land, then they should make it theirs instead of an
occupied territory and give the palestinians there full rights as citizens.
This may cause problems by shifting the balance of Jews to non-Jews and
may require some changes to accomodate the palestinians cultural desires
(i.e. religon schooling etc) - I dont know enough about Israel or the
Palestinians to judge the effect. If Israel does not want the land
then they should get rid of it either by letting the palestinians have
it or by giving it to one of the arab countries which border it. this
may have security repercussions which again I cant judge. As long
as the situation is kept in limbo (especially with the palestinians as
de facto non-entities) there will be tension, instability and unrest.
My slightly unifnormed opinion (which I think is held by some conservatives
in Israel) is that Israel should take option 1. Its theirs, now, neither
the arabs nor the palestinains have exhibited behaviour which should
induce Israel to be concillatory about land obtained in war.
---Liam
-------
∂03-Feb-88 1940 AI.BLEDSOE@R20.UTEXAS.EDU Re: Robert Halstead
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 19:40:35 PST
Date: Wed 3 Feb 88 21:40:28-CST
From: Woody Bledsoe <AI.BLEDSOE@R20.UTEXAS.EDU>
Subject: Re: Robert Halstead
To: JMC@SAIL.STANFORD.EDU
cc: AI.BLEDSOE@R20.UTEXAS.EDU, ATP.Bledsoe@R20.UTEXAS.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Wed 3 Feb 88 14:05:00-CST
Message-ID: <12371926215.8.AI.BLEDSOE@R20.UTEXAS.EDU>
John,
Thanks for the tip on Halstead.
I have talked to Al Dale about the TIAA contributions, and he is checking
into it. Depending on what he finds out, I will do what I can and let
you know.
I was great having you here last semester, and we miss you and yours.
Woody
-------
∂03-Feb-88 2210 JUSTESON@Sushi.Stanford.EDU Tasaday talk Thursday Feb. 4, noon
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 22:09:46 PST
Date: Wed 3 Feb 88 22:04:33-PST
From: John S. Justeson <JUSTESON@Sushi.Stanford.EDU>
Subject: Tasaday talk Thursday Feb. 4, noon
To: jmc@Sail.Stanford.EDU
Message-ID: <12371952443.14.JUSTESON@Sushi.Stanford.EDU>
Carol Molony in Anthro did some fieldwork with the Tasaday, and is going
to talk about that and about the controversy over them in the press,
in the Anthro department.
-- John
-------
∂04-Feb-88 0538 rms@wheaties.ai.mit.edu Boesch
Received: from frosted-flakes.ai.mit.edu ([128.52.32.19]) by SAIL.Stanford.EDU with TCP; 4 Feb 88 05:38:46 PST
Received: by frosted-flakes.ai.mit.edu; Thu, 4 Feb 88 08:38:18 EST
Date: Thu, 4 Feb 88 08:38:18 EST
From: rms@wheaties.ai.mit.edu (Richard Stallman)
Message-Id: <8802041338.AA01624@frosted-flakes.ai.mit.edu>
To: JMC@sail.stanford.edu
In-Reply-To: John McCarthy's message of 03 Feb 88 2239 PST <8802040636.AA17519@prep.ai.mit.edu>
Subject: Boesch
I got two messages from you about Boesch; thanks.
∂04-Feb-88 0800 JMC
waltuch
∂04-Feb-88 1036 P.PROMETHEUS@MACBETH.STANFORD.EDU honors project/csli internship
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 10:36:42 PST
Date: Thu 4 Feb 88 10:35:48-PST
From: Reid Hoffman <P.PROMETHEUS@MACBETH.STANFORD.EDU>
Subject: honors project/csli internship
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12372089204.215.P.PROMETHEUS@MACBETH.STANFORD.EDU>
Hi. My name is Reid Hoffman and I am a (junior) symbolic systems
major. I would like to ask for some guidance in my honors thesis,
and possibly work with you on a proposal for a summer CSLI
internship. Prof. Galison (history and philosophy of science)
has already agreed to help me with analysis and writing: however,
he does not know enough about AI to lead me to the sources of
information. From research on my own, I have amassed 4 potential
research ideas:
1) A historical and scientific comparison of Russian cybernetics
with American AI. This would include an examination of the goals
of each project, the different methodologies, (perhaps) different
conceptions of intelligence, the historical context (especially
any cold war rivalry), how each affects and is affected by social
institutions, and so forth.
2) Behaviorism in AI. AI seems to work with an operational
definition of intelligence: if it seems to behave intelligently
then it is intelligent. This method of viewing intelligence and
the consequent method of analysis reminds me of behaviorism, the
semi-defunct psycholigical paradigm of the 60s. There also seems
to be a problem for AI in that it tries to replicate something
which is very hard to study from the third person: we all have
first-person access to our intelligence. So, then, do we know
if we are creating an intelligence--is consciousness a
prerequisite for intelligence?
3) The problem of modularity. Much of the research in AI is
focused on solving small toy problems. In doing this, intelligence
is fractured into its components: "learning", "natural language
understanding", "search", "reasoning", etc. There seems to be
a dual problem here: first, that all these components are
intertwined and cannot be understood seperately (the other parts
cannot be assumed to be understood later), and that this approach
leads to making models to perfectly answer some small toy problems
instead of focusing on more broad research on intelligence.
4) AI is practised in many different ways: indeed, each institution
seems to have its inbred AI program. A comparison of the projects
of these AI programs (with an eye towards history) might shed some
interesting lot on AI. (also thinking about a comparison with
Tokyo and Edinburough.)
I would like to know if you think any of these four ideas has
merit to them, and where I could access pertinent information.
I would also like to know if you would be interested in doing
a CSLI project with me: either in one of these areas or something
else you would suggest. Finally, I would like to meet with you
to talk about these ideas.
thanks very much,
reid
-------
∂04-Feb-88 1126 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 11:26:39 PST
Date: Thu 4 Feb 88 11:19:56-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12372097240.42.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30
February 5: Prof. John Mitchell (Stanford Univ.),
"Introduction to Polymorphic Lambda Calculi"
PLEASE NOTE THE CHANGE OF ROOM: *** MJH 252 ***
February 12: Dr. Leslie Lamport (DEC-SRC),
"What Good is Temporal Logic?"
(as usual in MJH 301)
-------
∂04-Feb-88 1215 DEK Monday the 15th
is a university holiday, so you might want to take advantage of the
long weekend. For me it will be a Monday like other Mondays, so
our lunch date is OK by me; but I thought I'd doublecheck to see
if you really want to go ahead as we said. I suppose you would
like to talk with me before my meeting with Nilsson-Gibbons-Rosse
on Friday the 19th. I could bike over the the Faculty Club from
home on Tuesday or Wednesday the 16th or 17th just as easily
as on Monday the 15th...
∂04-Feb-88 1248 BEDIT@Score.Stanford.EDU Summary of December computer charges.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 12:47:54 PST
Date: Thu 4 Feb 88 12:32:36-PST
From: Billing Editor <BEDIT@Score.Stanford.EDU>
Subject: Summary of December computer charges.
To: MCCARTHY@Score.Stanford.EDU
Message-ID: <12372110469.11.BEDIT@Score.Stanford.EDU>
Dear Mr. McCarthy,
Following is a summary of your computer charges for December.
Account System Billed Pct Cpu Job Disk Print Adj Total
JMC SAIL 2-DMA705T 100 87.54 69.97 ***.** .00 5.00 2557.52
MCCARTHY SCORE 2-DMA705T 100 1.00 2.13 6.88 .00 5.00 15.01
MCCARTHY SUSHI SUSHI 100 .00 .00 .00 .00 .00 .00
Total: 88.54 72.10 ***.** .00 10.00 2572.53
University budget accounts billed above include the following.
Account Principal Investigator Title
2-DMA705 McCarthy N00039-84-C-0211
The preceding statement is a condensed version of the detailed summary sheet
sent monthly to your department.
Please verify each month that the proper university budget accounts are paying
for your computer usage. Please also check the list of account numbers below
the numeric totals. If the organizations/people associated with that account
number should NOT be paying for your computer time, send mail to BEDIT@SCORE.
Please direct questions/comments to BEDIT@SCORE.
-------
∂04-Feb-88 1253 jcm@navajo.stanford.edu Proposal for new course.
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Feb 88 12:53:36 PST
Received: by navajo.stanford.edu; Thu, 4 Feb 88 12:49:39 PST
Date: Thu, 4 Feb 88 12:49:39 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: Proposal for new course.
To: jmc@sail.stanford.edu, pratt@navajo.stanford.edu, zm@sail.stanford.edu
I would like to propose the following course for next year.
Any comments at this point would be appreciated. Thanks.
--------------
CS ???. Introduction to Programming Language Theory
Syntactic, operational and semantic issues in the mathematical
analysis of programming languages. Type systems and non-context-
free syntax. Operational semantics given by rewrite rules;
confluence and termination. General framework and goals of
semantic models; Scott-style domain constructions for simple
languages with higher-type functions and recursion. Treatment
of side-effects. Polymorphism, data abstraction and inheritance.
Prerequisite: CS 157, Phil 160A, or consent of instructor.
∂04-Feb-88 1358 pratt@chehalis Re: Proposal for new course.
Received: from chehalis.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Feb 88 13:58:40 PST
Received: by chehalis.stanford.edu (4.0/SMI-DDN)
id AA00798; Thu, 4 Feb 88 13:58:24 PST
Message-Id: <8802042158.AA00798@chehalis.stanford.edu>
To: John Mitchell <jcm@navajo.stanford.edu>
Cc: jmc@sail.stanford.edu, pratt@navajo.stanford.edu, zm@sail.stanford.edu
Subject: Re: Proposal for new course.
In-Reply-To: Your message of Thu, 4 Feb 88 12:49:39 PST.
<8802042053.AA00726@chehalis.stanford.edu>
Date: 04 Feb 88 13:58:22 PST (Thu)
From: pratt@chehalis
Sounds like it should be numbered CS 258. Good syllabus.
However, not to be a wet blanket and all that but perhaps we should get
together first and decide whether there is a larger subject that this
is a well-defined part of. I'm all for designing a full MTC syllabus,
the goal of which would be to bring students up to the state of the MTC
art. Definition of MTC an agenda item.
-v
∂04-Feb-88 1429 DEK
∂04-Feb-88 1302 PHY
∂04-Feb-88 1258 JMC re: Monday the 15th
To: DEK
[In reply to message rcvd 04-Feb-88 12:15-PT.]
Monday the 15th is fine with me, but the Faculty Club won't be
open. Suppose I come by your house and we go to lunch somewhere
in Palo Alto?
*** Thanks for the suggestion. Fine with me, see you then.
∂05-Feb-88 0900 JMC
waltuch
∂05-Feb-88 0931 MPS Keynote Speech
Prof. Golshani (Arizona State) your host for the conference
on computers and communication (mid-March) would like to
talk to you about a few things.
Pat
∂05-Feb-88 0933 MPS phone number
Sorry about that. Guess you cannot call him unless
you hve a phone number. It is 602 965-2855.
Pat
∂05-Feb-88 0948 Qlisp-mailer LIFO and FIFO queues, single and multiple queues, fib, qempty
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 09:47:57 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01689; Fri, 5 Feb 88 09:47:58 pst
Date: Fri, 5 Feb 88 09:47:58 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8802051747.AA01689@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: LIFO and FIFO queues, single and multiple queues, fib, qempty
LIFO vs. FIFO
Joe pointed out that a FIFO system results in bread-first execution
of a program. In the case of FIB this can be bad, as the entire
computation tree gets spawned simultaneously. A FIFO system may have
a tendency to break if the program has sufficient parallelism. Using
QLET T, Fib breaks at (FIB 17). With a STACK however, the computation
is depth first. There are some programs which probably would run
faster on the breadth-first model, however, such a model would
discourage extensive parallelism.
Multiple vs. Single
Using CSIM, we discovered that there was potentially alot of
contention at certain resource points, such as the *free-list* for
cons and the *process-queue* for processes. In general, with a
spin-lock system, it became apparent that the contention for a
bottle-necked resource increases as the square of the number of
processors. It was for this reason that the N-Stack scheduler was
developed, to distribute and for practical purposes eliminate
contention for the *process-queue*. However, with only 4 processors,
contention is roughly at the noise level. It might become noticeable
with 8 processors. With 4 processors, the contention noticeable only
for programs which spawn processes but do very little computation.
And if processes need to be dynamically allocated (they don't), then
allocation dominates the contention.
FIB, QEMPTY and depth cutoffs
From a programming languages point of view, a depth cutoff is not
desirable. The correct depth to use is not always determinable; it
may depend highly on the input, even if it is determinable; it could
be tunable for differing numbers of processors; it does not take into
account that there may be other parts of the program already running
in parallel and dominating the usage of the processors.
From a languages point of view, QEMPTY is a superb predicate. It does
not require tuning for different programs or numbers of processors. It in
some sense takes into account that other parts of the program may be using
most of the processors, and it is very cheap to evaluate. The only question
is DOES IT WORK? With a single stack, QEMPTY stinks, as has been mentioned.
However, what, exactly, is its behavior on Nstacks?
An inductive examination is appropriate. Assume, initially, that each
processor has a large task and all process stacks are empty. Also,
assume the tasks are identical in size. Fairly immediately, each
processor spawns a task which is half the size of its original, and
continues working on the other half. Clearly, if the computation tree
for a task is a complete binary tree, then the number of tasks spawned
by a processor is equal to the depth of the tree, or in some sense,
the LOG of the SIZE of the task.
The question is, what happens when the tasks differ slightly in size?
Then one processor (P1) finishes before the others. It steals a task
from a different stack (P2's), and continues as before, with
logarithmic performance. P2, who was robbed, gets annoyed and spawns
a possibly trivial task. Say a third processor, P3, empties its stack
of tasks. As it cycles through the other processors stacks looking
for someone to rob, it has equal chances of helping P1, who has a
significant task in its stack, or helping P2, by doing the trivial
task. This analysis is far from rigorous, and some detailed
experiments may help, but the result seems to show that the number of
tasks spawned in the balanced case is Log(SIZE), and in the less
balanced case, at least 2*Log(SIZE). Of course, in the completely
unbalanced case, O(SIZE) tasks may be spawned.
-dan
∂05-Feb-88 0948 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
COMPILING CIRCUMSCRIPTIVE THEORIES INTO LOGIC PROGRAMS
Vladimir Lifschitz
Stanford University
Friday, February 5, 3:15pm
MJH 301
In this work, joint with Michael Gelfond, we study the possibility of
reducing some special cases of circumscription to logic programming. The
description of a given circumscriptive theory T can be sometimes transformed
into a logic program P, so that, by running P, we can determine whether a
given ground literal is a theorem of T. The method is applicable, in
particular, to some formalizations of tree-structured inheritance systems
with exceptions.
∂05-Feb-88 1023 MPS Sequent Computer
Don McAlister (408 436-8448) talked to Les about Qlisp.
It was Les who suggested Don talk to you about the
potential of looking at Sequent's product for the
future use with the Qlist projects.
Pat
∂05-Feb-88 1159 pratt%jah@Sun.COM Re: New Course: CS 258
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 11:59:27 PST
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA22178; Fri, 5 Feb 88 11:59:59 PST
Received: from jah.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA26369; Fri, 5 Feb 88 11:52:40 PST
Received: by jah.sun.com (3.2/SMI-3.2)
id AA21102; Fri, 5 Feb 88 11:57:40 PST
Date: Fri, 5 Feb 88 11:57:40 PST
From: pratt%jah@Sun.COM (Vaughan Pratt)
Message-Id: <8802051957.AA21102@jah.sun.com>
To: Zohar Manna <ZM@sail.stanford.edu>
Cc: jcm@navajo.stanford.edu, jmc@sail.stanford.edu
Subject: Re: New Course: CS 258
In-Reply-To: message of 05 Feb 88 1031 PST.
<8802051833.AA20653@Sun.COM>
It's fine by me. (That was the same number I guessed at.)
Is there any MTC interest in planning in the large? Or are we all
up to our keeshters in treacle?
-v
∂05-Feb-88 1304 forbus@p.cs.uiuc.edu QPW-88: CALL FOR PAPERS
Received: from a.cs.uiuc.edu by SAIL.Stanford.EDU with TCP; 5 Feb 88 13:04:35 PST
Received: from p.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA10585; Fri, 5 Feb 88 15:04:12 CST
Received: by p.cs.uiuc.edu (UIUC-5.52/9.7)
id AA28826; Fri, 5 Feb 88 14:00:27 CST
Date: Fri, 5 Feb 88 14:00:27 CST
From: forbus@p.cs.uiuc.edu (Kenneth Forbus)
Message-Id: <8802052000.AA28826@p.cs.uiuc.edu>
To: JMC@SAIL.STANFORD.EDU
Subject: QPW-88: CALL FOR PAPERS
Dear collegue:
The purpose of this note is to spread the word about the upcoming
Qualitative Physics Workshop. I would greatly appreciate it if you
could post the call for papers, included below, in some appropriate
fashion. Unfortunately, we were too late to make the last issue of
the AI magazine, and as you can see from the deadline (March 8th) the
next issue would be too late.
Please note: The coincidence of the deadline with AAAI-88 is not an
accident. Since no proceedings will be generated from this workshop,
submitting an extended abstract based on work submitted to AAAI-88
would be appropriate. This was our way of ensuring that we would get
to discuss top-quality work, without entering into competition with
AAAI and IJCAI.
This call for papers has already appeared on AI-List, so if you saw it
there and your group is already aware of the workshop, I apologize for
the duplication. But if you did not see the original posting, then at
least we've reached you this way, and ask that you spread the word to
others who might also have been missed.
Thank you for your cooperation.
Ken Forbus
======================================================================
CALL FOR PARTICIPATION
SECOND WORKSHOP ON QUALITATIVE PHYSICS
PARIS, JULY 26-28, 1988
Following last year's success of the first workshop on Qualitative
Physics organized by the Qualitative Reasoning Group at the University
of Illinois (with AAAI sponsorship), the second workshop on
Qualitative Physics will be organized by the European Group on
Qualitative Physics and the IBM Paris Scientific Center. The
workshop, sponsored by the Commission of the European Community
(JRC-Ispara) and in cooperation with AAAI, will be held in Paris on
July 26-28, 1988. It is intended as a forum for discussion for
ongoing research in Qualitative Physics and related areas.
To develop interaction and exchange of ideas, a number of panels will
be organized. We invite proposals for panels on ongoing debates in
the area, such as:
-- Causal Reasoning
-- Mathematical Aspects of Qualitative Models
-- Naive Physics versus Qualitative Physics
Another suggested panel format is to pose a particular problem which
panelists must use to focus discussion. Proposers for panels should
obtain the agreement of the panelists and submit the proposal,
including an outline of the suggested discussion, to the program
chairman by March 8, 1988.
ATTENDANCE:
To encourage lively discussion, attendance will be by invitation only.
If you are interested in attending, please submit five (5) copies of
an extended abstract, up to 6 pages long, to the program chairman:
Francesco Gardin
Dipartimento di Scienze dell'Informazione,
Universita degli Studi di Milano
Via Moretto da Bresica, 9
20133 Milano, ITALY
tel. +39-2-2141230
The deadline for submissions is MARCH 8th, 1988 and invitations will be
mailed APRIL 5th, 1988. Abstracts will be reviewed by an international
scientific committee. Results already submitted for publication elsewhere
are acceptable since no proceedings of the workshop will be published.
A subset of the authors may be asked to contribute to a book based on the
workshop. Besides presenters of papers, a limited number of observers
may be accepted. For further information about the organization of the
workshop, contact any member of the organizing committee, or:
Olivier Raiman
IBM Paris Scientific Center
3/5 Place Vendome,
75001 Paris, FRANCE
tel. +33-1-4296-1475
====================
ORGANIZING COMMITTEE
Johan De Kleer (Xerox PARC)
Ken Forbus (University of Illinois, Urbana)
Pat Hayes (Xerox PARC),
Ben Kuipers (University of Texas, Austin)
and all the members of the European Qualitative Physics Committee:
Flavio Argentesi (JRC-Ispra)
Ivan Bratko (University of Ljubljana)
John Campbell (Univ. College of London)
Jean-Luc Dormoy (EDF)
Boi Faltings (E.P.F. Lausanne)
Francesco Gardin (University of Milan)
Bernd Hellingrath (Fraunhofer-Institute ITW)
Roy Leitch (Heriot-Watt University)
Nicools J. Mars (Univ. of Twente)
Pierre Van Nypelseer (AITECH, Brussels)
Olivier Raiman (IBM Paris Scientific Centre)
Peter Struss (Siemens)
-------------------------------------------------------------------
∂05-Feb-88 1424 Qlisp-mailer Number of spawns with qemptyp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 14:22:26 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02647; Fri, 5 Feb 88 14:22:31 pst
Date: Fri, 5 Feb 88 14:22:31 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8802052222.AA02647@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Number of spawns with qemptyp
Before doing experiments, I suggested that the number of spawns was at
least 2*log(size) for slightly unbalanced trees. Due to various
random factors, even a balanced tree may schedule unevenly using
qemptyp.
I did some experiments which seem to indicate that the number of
spawns goes up as log(size) squared. After further consideration of
Qemptyp's behavior, this may make more sense than 2*log(size).
If anyone would like to see this data, just send me a message. -dan
∂05-Feb-88 1503 M.MAURYCE@MACBETH.STANFORD.EDU An Interview with U
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 15:03:15 PST
Date: Fri 5 Feb 88 14:59:41-PST
From: Cheryce Kramer <M.MAURYCE@MACBETH.STANFORD.EDU>
Subject: An Interview with U
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12372399387.238.M.MAURYCE@MACBETH.STANFORD.EDU>
Hello John,
Stuart Reges told me about you in connection with an article that
I am going to write about email systems and how this new medium is
minting a whole new form and forum of communication...
He said that you were a person who kept up on the discussions in
several bboards and that you might have some intersting theories about this
new mode of interaction.
I'm sure that you are very buisy but would still like to ask if
it would be possible to squeaze in a short interview for me sometime.
Since my article needs to go to the newspaper in about 2 and a half weeks
I would appreciate as early a date as you are able to arrange.
I'm looking for the following:
what kinds of topics are discussed.
how are they treated differently on email than in letters or in person
or on the telephone.
is there a new sense of humor.
etc...
My username: m.mauryce
Cheryce Kramer
tel: 324 98900
Thanx again,
cheryce
ps--the article is for the economist if that is of any interest.
-------
∂05-Feb-88 1503 Qlisp-mailer Current lock operations are expensive.
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 15:03:29 PST
Date: Fri, 5 Feb 88 14:52:38 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.Stanford.EDU>
Subject: Current lock operations are expensive.
To: qlisp@sail.Stanford.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12372398104.15.OKUNO@SUMEX-AIM.Stanford.EDU>
This is some result of NAIVE parallel ATMS written in QLISP on Alliant
FX8 with 4 processors. This implementation exploits only concurrent
processing of justifications and nogoods and has many locks to control
critical sections. It seems to me that locking operations are very
expensive, because execution of QLISP program under TIME (that is,
one-processor) is about 40% slowerer than that of the same lock-less
program under LUCID CL. Processes are spawned only by ATMS
application programs and both programs have only three QLET's with
four QLET variables, respectively. The number of processes spawned in
4-processor QLISP is as follows:
1 proceeses are in use.
0 proceeses are blocked.
13 proceeses are used.
16 proceeses are scheduled.
Any comments or suggestions?
Thanks in advance,
- Gitchang -
********************
[ATMS application program A]
Alliant FX8 Alliant FX8 Alliant FX8
4-processors 1-processor uni-processor Explorer-I Explorer-II
QLISP QLISP LUCID CL 8Mbyte 16Mbyte Phy. Mem
----------------------------------------------------------------------
485sec 1647sec 1132sec 1464sec 379sec
[ATMS application program B]
4-processors 1-processor uni-processor Explorer-I Explorer-II
QLISP QLISP LUCID CL 8Mbyte 16Mbyte Phy. Mem
----------------------------------------------------------------------
83sec 316sec 79sec 53sec 32sec
********************
-------
∂05-Feb-88 1609 DEK gosper visit
I'll be there soon; have to write an urgent letter first.
∂05-Feb-88 1646 GINSBERG@Sushi.Stanford.EDU yet *another* way to waste some time?
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 16:46:28 PST
Date: Fri 5 Feb 88 16:40:55-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: yet *another* way to waste some time?
To: mugs@Score.Stanford.EDU, principia@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, val@Sail.Stanford.EDU, shoham@Score.Stanford.EDU
Message-ID: <12372417817.12.GINSBERG@Sushi.Stanford.EDU>
Hi All:
I was thinking of organizing an informal biweekly lunch meeting
for the formalists around here. The intention would be that
students could ask questions about results (or anything else!)
that they found puzzling, that people could present half-baked
ideas, and so on. There would never be any formal presentations;
the most "structured" things would ever be would be to give people
who ran out of time at one meeting priority at the next. No overhead
projectors; no need to defend ideas in terms of relationship to
results elsewhere in the literature; just constructive stuff all
around.
The idea is based on research meetings I participated in at Oxford,
which were structured roughly like this, and which I found tremendously
useful. Anyway, I wanted to get people's opinions on:
(1) Would you participate? Participate probably means "talk", at
least from time to time.
(2) Is Thursday OK? Tuesdays and Fridays are out for sure, and
Mondays are pretty bad for me. Wednesday is often Planlunch ...
Anyway, let me know! If there is interest, I'll aim for a first
meeting on February 25 ...
Matt
-------
∂05-Feb-88 1717 jcm@navajo.stanford.edu Re: Proposal for new course.
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 5 Feb 88 17:17:29 PST
Received: by navajo.stanford.edu; Fri, 5 Feb 88 17:13:30 PST
Date: Fri, 5 Feb 88 17:13:30 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: Re: Proposal for new course.
To: jcm@navajo.stanford.edu, pratt@chehalis.stanford.edu
Cc: jmc@sail.stanford.edu, pratt@navajo.stanford.edu, zm@sail.stanford.edu
I wrote up the syllabus for what might be CS 258 based on
what I thought was missing from the curriculum, and what
I am most interested in teaching. It could easily grow
to be an A,B sequence, or be part of some redesigned
series of courses. Some obviously worthwhile topics that
are left out are:
1. logics of programs: Floyd-Hoare logic, dynamic logic,
temporal logics of programs, various extensions
of Hoare logic to concurrent programs, proving
properties of Lisp programs, "type theoretic"
approach using Nuprl, Calculus of Constructions, etc.
2. semantics of concurrency
3. various researchy problems in semantics: full abstraction,
strictness analysis, or, more generally, various
techniques for abstract interpretation and dataflow
analysis
4. categorical techniques in semantics and syntactic analysis
of programming languages: adjoint situations,
categorical approach to domain equations,
Karoubi envelope and "definability" of constructs
(i.e. syntax-independent approach to studying
comparative expressiveness of various languages)
5. implementation techniques based on operational or
denotational "semantics:"
categorical abstract machine (a la INRIA)
various ways to implement beta-reduction
using graphs and related data structures
other stuff from Peyton-Jones' book
6. data types defined by specifications:
reasoning from specifications
initial and final algebra semantics
implementing data types from equational specs
And I'm sure there are a lot of other things that I
can't think of right now.
What is the general consensus about organizing some of
these, or other topics into courses and making plans to
teach them? (As Vaughan seems to be suggesting.)
∂05-Feb-88 2156 Qlisp-mailer timing Qlisp programs
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 21:56:26 PST
Received: from SAIL.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04010; Fri, 5 Feb 88 21:56:34 pst
Message-Id: <8802060556.AA04010@Gang-of-Four.Stanford.EDU>
Date: 05 Feb 88 2156 PST
From: Ron Goldman <ARG@SAIL.Stanford.EDU>
Subject: timing Qlisp programs
To: qlisp@Gang-of-Four.Stanford.EDU
This message is a reminder to anyone timing their Qlisp programs that all
of their experiments should be done using the same version of Qlisp.
Comparisons using different versions of Qlisp will usually not mean too much,
at least until we stop making major changes. For example the current
new-qlisp uses a simple deep-binding scheme which is not very efficient, so
if a program makes much use of specials it will run much slower than it would
in the more stable qlisp image. Likewise using any older Lisp images on
gang-of-four will produce timing differences due to many changes in the
internals of Lisp made for Qlisp. To further complicate matters, we'll be
improving the new-qlisp soon. So other than testing for the effects of our
improvements, you won't be able to compare times of programs run in the
current new-qlisp with those run in the next new-qlisp. Of course we'll
send out a message whenever we make any major changes, but be forewarned.
Ron
∂06-Feb-88 1240 jbn@glacier.stanford.edu A third path to artificial intelligence
Received: from glacier.stanford.edu by SAIL.Stanford.EDU with TCP; 6 Feb 88 12:40:33 PST
Received: by glacier.stanford.edu; Sat, 6 Feb 88 12:41:00 PST
Date: Sat, 6 Feb 88 12:41:00 PST
From: John B. Nagle <jbn@glacier.stanford.edu>
Subject: A third path to artificial intelligence
To: JMC@sail.stanford.edu
There is a third approach to artificial intelligence, but it is new
enough that it does not yet have a name. It might be called the "artificial
animal" approach. The basic tenet of those following this path is that
human-level artificial intelligence seems to be a harder problem than
anticipated, perhaps one too difficult to tackle directly given our present
level of understanding. It is therefore desireable to look for problems
which appear less daunting but whose solution will provide us with an
understanding of some important functions performed by living brains.
The construction of systems which perform some of the functions of
the brains and nervous systems of animals is therefore a way to attack
the problem. By starting with very simple animals, and working up,
it may eventually be possible to reach and pass the human level.
Rod Brooks, with his artificial insects, is probably the most vocal
exponent of this approach. Raibert's studies of balance and locomotion,
Moravec's efforts in navigation, Brathenberg's simple robots, and several
efforts in the motion vision area seem to follow this model.
There is a recognition that this approach is not going to lead to
a "magic bullet" solution that "cracks the AI problem". This road is
long. It may be possible to take a shortcut. But if the shortcuts
don't work, this road will probably get there eventually. And in any case,
engineered artificial animals will be useful machines in their own right.
A near-term result should be the development of robots which, while perhaps
not intelligent, are able to function in the real world.
For myself, I've decided to spend a few years going in this
direction.
John Nagle
∂06-Feb-88 1551 mcvax!inria.inria.fr!queinnec@uunet.UU.NET re: IWoLES
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 6 Feb 88 15:51:47 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA27620; Sat, 6 Feb 88 18:52:05 EST
Received: by mcvax.cwi.nl; Fri, 5 Feb 88 01:29:22 +0100 (MET)
Received: by inria.inria.fr; Thu, 4 Feb 88 21:51:01 +0100 (MET)
Date: Thu, 4 Feb 88 21:51:01 +0100
From: mcvax!inria.inria.fr!queinnec@uunet.UU.NET (Christian Queinnec)
Message-Id: <8802042051.AA10020@inria.inria.fr>
To: JMC@sail.stanford.edu
Subject: re: IWoLES
Can i put your notes in the proceedings ? I can compose it with LaTeX
if you want.
Christian Queinnec
∂07-Feb-88 0957 sdcsvax!hp-sdd!sceard!mrm@rutgers.edu Re: two extreme approaches to AI
Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 7 Feb 88 09:57:42 PST
Received: by rutgers.edu (5.54/1.15)
id AA29692; Sun, 7 Feb 88 12:31:06 EST
Received: by icarus.riacs.edu (5.54/2.0G)
id AA25961; Sun, 7 Feb 88 09:05:48 PST
Received: by XN.LL.MIT.EDU; Sun, 7 Feb 88 12:04:32 EST
Posted-Date: 7 Feb 88 07:58:05 PST (Sun)
Received: Sun, 7 Feb 88 08:58:27 PST by ames.arc.nasa.gov (5.58/1.2)
Received: from hp-sdd.HP.COM (hp-sdd) by hplabs.HP.COM with SMTP ; Sun, 7 Feb 88 08:06:26 PST
Received: by hp-sdd.HP.COM; Sun, 7 Feb 88 08:07:22 PST
Return-Path: <hp-sdd!sceard!mrm>
Received: by sceard.UUCP (smail2.5)
id AA03525; 7 Feb 88 07:58:05 PST (Sun)
To: JMC@sail.stanford.edu
Subject: Re: two extreme approaches to AI
Newsgroups: comp.ai.digest
In-Reply-To: <8802050734.AA06046@ucbvax.Berkeley.EDU>
Organization: Sceard Systems, Inc., Carlsbad, CA 92009
Message-Id: <8802070758.AA03525@sceard.UUCP>
Date: 7 Feb 88 07:58:05 PST (Sun)
From: sdcsvax!hp-sdd!sceard!mrm@rutgers.edu (M.R.Murphy)
The relative lack of NI as opposed to AI may make the second
approach, and for that matter, the first approach, difficult :-)
∂07-Feb-88 1326 VAL
Please take a look at nsf[1,val], p. 2.
∂07-Feb-88 1333 nilsson@Tenaya.stanford.edu your memo of 2/2/88
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 7 Feb 88 13:33:35 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03160; Sun, 7 Feb 88 13:33:31 PST
Date: Sun, 7 Feb 88 13:33:31 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802072133.AA03160@Tenaya.stanford.edu>
To: floyd@score, guibas@score, dek@sail, zm@sail, jmc@sail, pratt@score,
ullman@score
Subject: your memo of 2/2/88
Your analysis of the "foundations situation" seems compatible with the
strong recommendations of the visiting committee (about which more
later when I have time). Suffice it to say now, that I have decided that
solving the foundations problems is my number one priority, and I'll be
devoting much time to that starting immediately. Even though you are all
super-busy, I hope I will be able to depend on you all for advice and
occasional help. When your recommendations to me depart from a consensus
of all of you, I hope you will understand that sometimes it's better to
be definite and unambiguous even if seemingly arbitrary to some. I
don't intend to be indefinite!
-Nils
∂07-Feb-88 1347 VAL
Please unprotect files[1,jmc].
∂07-Feb-88 1458 VAL Book
We promised to deliver the manuscript on Feb. 15, and I'll try to make it.
I'm planning to fully concentrate on this project now, and obviously I'll
have to bother you with questions and requests all the time. Here is the
first batch:
1. Your 1980 circ'n paper is supposed to be CIRCUM.TEX[s79,jmc], but there is
no such file. Is there an approximation better than CIRCUM.w80[w80,jmc]?
2. How can I get access to peano:>jmc>know.tex.4? (It is the version of
"Two Puzzles" you created during my last visit to Austin.)
3. Should I assume that your IJCAI-77 paper, "Epistemological problems",
and the report on coloring maps haven't been TeXed?
4. Is MRHUG[S76,JMC] the best that we have on Mr. Hug?
∂07-Feb-88 1534 VAL re: Book
[In reply to message rcvd 07-Feb-88 15:27-PT.]
Thank you for the quick reply. I'm planning to check every paper that has been
published against the published text.
∂07-Feb-88 1705 Qlisp-mailer Re: timing Qlisp programs
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 17:05:29 PST
Date: Sun, 7 Feb 88 17:04:49 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.Stanford.EDU>
Subject: Re: timing Qlisp programs
To: ARG@SAIL.Stanford.EDU
cc: qlisp@SAIL.Stanford.EDU
In-Reply-To: <8802060556.AA04010@Gang-of-Four.Stanford.EDU>
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12372946454.11.OKUNO@SUMEX-AIM.Stanford.EDU>
I'm sorry that I haven't dreamt of the fact that new-qlisp is a
deep-binding lisp, although I know that the next QLISP version will be
one. This fact explains some strange timings of my programs.
Anyway, this is the new result:
-------------------------------------------------------------------------
Shallow-bind QLISP Deep-bind QLISP
with-lock and single processor: 1240sec 1647sec
sequential implementation: 1132sec 1432sec
-------------------------------------------------------------------------
Thus, the overhead of with-lock is about 10% for my program. The
number of calling of with-lock is 137221. Most of with-lock look like
(with-lock (*lock-for-global-variable*)
(push value *gloval-variable*) )
and it seems slow to access global variables under current
implementation. One way to speed up an access to global variables is
to provide a special function, say, VALUE (in TAO), to get the value
of the value-field of a variable.
According to our experience on deep-binding Lisp (TAO), variable cache
for special variables is very effective, although simple benchmarks
such as STAK show poorer performance with variable cache than without
it. Our result is that the interpreted codes of some expert system on
TAO/ELIS runs as fast as compiled codes of Symbolics-3600. Thus, I
hope that LUCID will develop a very efficient implementation of
deep-binding Lisp. Last but least, the performance of QLISP system
should be compared with the best sequential Common Lisp system on the
same machine (or a machine of similar architecture). That's why I
used a different system. However, it was my fault to say that locking
operation was slow by comparing data of different systems.
Regards,
- Gitchang -
-------
∂07-Feb-88 1730 jlh@vsop.stanford.edu Re: Bert Halstead
Received: from vsop.stanford.edu by SAIL.Stanford.EDU with TCP; 7 Feb 88 17:30:50 PST
Received: by vsop.stanford.edu; Sun, 7 Feb 88 17:28:34 PST
Date: 7 Feb 1988 1728-PST (Sunday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc:
Subject: Re: Bert Halstead
In-Reply-To: John McCarthy <JMC@sail.stanford.edu> /
05 Feb 88 1242 PST.
I'd guess I'd be surprised, although betting on MultiLISP is probably
still betting on the future.
He should certainly apply to Pratt's programming language search.
John
∂07-Feb-88 1918 Qlisp-mailer timing Qlisp programs
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 19:18:30 PST
Received: by labrea.Stanford.EDU; Sun, 7 Feb 88 19:18:47 PST
Received: from bhopal.lucid.com by edsel id AA23404g; Sun, 7 Feb 88 19:07:41 PST
Received: by bhopal id AA14024g; Sun, 7 Feb 88 19:12:18 PST
Date: Sun, 7 Feb 88 19:12:18 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802080312.AA14024@bhopal.lucid.com>
To: Okuno@sumex-aim.stanford.edu
Cc: labrea!qlisp%SAIL@labrea.Stanford.EDU
In-Reply-To: Hiroshi "Gitchang" Okuno's message of Sun, 7 Feb 88 17:04:49 PST <12372946454.11.OKUNO@SUMEX-AIM.Stanford.EDU>
Subject: timing Qlisp programs
re: One way to speed up an access to global variables is
to provide a special function, say, VALUE (in TAO), to get the value
of the value-field of a variable.
I assume that TAO's VALUE function isn't simply equivalent to Common
Lisp's SYMBOL-VALUE, as the latter must fetch any dynamically bound
value in preference to a truly "global" value.
It's likely that some performance problems will arise if a program uses
deep-bound access to what are truly global variables. Common Lisp itself
doesn't provide enough primitives to make a proper distinction here. I'm
attaching to this mail a copy of a note circulated during 1985 to help
prepare Lucid (and others) for the eventual use of a deep bound lisp. In
particular, we still need the equivalent of what Interlisp provides to get
the "global", as opposed to the dynamic value, of a variable.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
A serious shortfall exists in the defined capabilities for treating
variables either as global or as dynamic, which will badly impact the user
trying to write sensible code runnable both in a deep bound implementation
and in a shallow bound one. Common Lisp has gone on record as not being
limited to shallow-bound implementations, and with the appearance of
multi-processor work-stations and "computers", the issue of a deep-bound
implementation of CL is coming to reality.
This note is rather long, so I've organized the remainder into
four sections, with the the more important items first.
** Statement of the Problem
** Comparisons with Deep- and Shallow-Bound Interlisps
** A Noticeable Semantic Distinction
** Benefits of Distinction
Statement of the Problem
In Commonlisp Lisp, there is no means to specify that a variable's
references are "global" rather than dynamic [of course, this only applies
to free variable references -- global variables may not be bound].
Section 5.3.2 of the CL manual recommends 'defvar' as the means to declare
a variable as special, and (unwisely, I think) suggests this as the means of
defining "globally defined variables"; defconstant adddresses an issue not
really related to "variables", but rather to named constants (i.e., you cannot
setq a symbol which has been defined by defconstant); defparameter isn't
quite right either, depending on one's implementation (most implementations
I've seen cause defparamater to do a SPECIAL proclaimation on the variable).
Comparisons with Deep- and Shallow-Bound Interlisps
Interlisp-10 is a shallow-bound implementation, whereas Interlisp-D and
Interlisp/VAX are deep bound; so this problem of distinction has already been
faced in that world. Since the shortfall is hardly perceptible to the user
of a shallow-bound implementation, I recommend reading that part of the
Interlisp reference manual dealing with the differences between the functions
GETTOPVAL, GETATOMVAL, and EVALV. [This is found in section 2.4.1 of the
Oct 1983 version of the IRM, and at the end of section 5.1 of the Oct 1978
version]. The comments therein about performance implications are not just
theoretical, but have been observed to account for an order-of-magnitude
difference between a poorly ported application and a properly ported one.
Interlisp's EVALV corresponds by definition to CL's 'symbol-value'
[note well: symbol-value is *not* defined by reference to a "value cell",
but rather to the dynamic binding environment]; but there is no CL equivalent
to GETTOPVAL, and GETATOMVAL.
A Proffered Solution
Actually, defvar "proclaims" a variable to be special; to meet the
problems of this shortfall, there would need to be a declaration of globality
for variables, just as there is a declaration of dynamic scoping for them (see
the "special" section of section 9.2 in the manual). The observable
differences between a variable of global scope and one of dynamic, or special,
scope are:
(1) it is an error to bind a global variable, but setq'ing is ok; and
(2) a deep-bound implementation would do a "shallow" value-cell fetch
for global references, rather than the kind of free-variable lookup
it must do for dynamic references.
Additionally, there should be a 'defglobalvar' which proclaims a variable to
be of global scope, just as defvar proclaims one to be of dynamic scope.
A Noticeable Semantic Distinction
In addition to the perceived performance loss (in the deep-bound case)
of not making accurate global declarations, there is in fact a semantic
difference discernible in both deep and shallow.
(setq x "Topval for x")
(defun lookat ()
(let ((x "Random dynamic val for x"))
(declare (special x))
(list (see-special) (see-global))))
(defun see-special () (declare (special x)) x)
(defun see-global () (declare (global x)) x)
When the global declaration is correctly done, the result of (lookat) will
be ("Random dynamic val for x" "Topval for x") rather than
("Random dynamic val for x" "Random dynamic val for x")
[Let me forstall any side-tracking discussion about the inadvisibility of
using a variable both globally and specially in the same module. This example
is only for illustrative purposes; the issue is really the protection of
one module's usages against those of others, just as a local variable in one
function needs to be sheilded from the dynamic bindings in another, lexically
different, function.]
Benefits of Distinction
For the record, I will say that I believe programmers have in general
overused dynamic variables in the past, ** particularly when attempting to
define global state variables -- I've seen a lot of code that mistakenly
defines some global variable, which in fact holds something that is process
dependent, or application dependent. I think this will change in the future,
due to the influence of Scheme and to the insistence by this community for
correct lexical scoping in Lisp interpreters. This statement is only a
generalization, but it comes from observing much code that had to be re-thought
very carefully in the face of a multi-processing Lisp. One must distinguish
global state in a machine,
such as *modules* (section 11.8 of CL manual),
or, say, *network-routing-table*
from dynamic state
such as *package* or *read-base*
or, say, *standard-output* (which will be process-specific, at least)
Properly used, each has their own place, that will become more individually
secure as deep-bound implementations of CL come into being.
-- JonL --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
∂08-Feb-88 0343 rivin@Gang-of-Four.Stanford.EDU QLISP budget draft
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 03:43:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA09147; Mon, 8 Feb 88 03:43:02 pst
Date: Mon, 8 Feb 88 03:43:02 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802081143.AA09147@Gang-of-Four.Stanford.EDU>
To: jmc@sail, les@sail
Subject: QLISP budget draft
The budget email to boesch is beneath the dotted line. I guesstimated
the cost of Gabriel & co's foreign travel. Is the comment re Alliant
upgrade reasonable? Please let me know asap, so I can mail this off...
--------------------------------------------------------------------------
Here is a draft of the proposed budget for the next 18 months. I hope
this has all the information you need. If not, please let me know.
The budgeted amount for upgrading the Alliant FX/8 to the eight
processor configuration is only a rough estimate
(the line that says Capital equipment: 4 processors, 1 cache, 32meg)
We should have a quote from Alliant shortly, however.
Igor
Proposal to DARPA
for
QLISP on Parallel Processors
Budget for 18 months beginning 1 March 1988
Personnel 18 Month Cost
Prof. John McCarthy (25% acad. yr., 50% Sum.) 47,087
William Gosper, Sr. Research Assoc. (100%) 90,000
Igor Rivin, Research Assoc. (100%) 72,216
Arkady Rabinov, Research Assoc. (100%) 83,214
Carolyn Talcott, Reseach Assoc. (50%) 40,842
Joe Weening, Research Assoc. (100%) 72,000
Dan Pehoushek, Research Programmer (100%) 43,506
Alex Gorbis, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
Pat Simmons, Secretary (50%) 15,993
---------
Salary Base 554,098
Allowance for salary increases 18,470
(5% beginning 9/1/88)
---------
Salary Total 572,568
Staff benefits (26.2% till 9/1/88, 153,448
27.1% thereafter)
Consultants (10 days/yr. @ $600) 6,000
Travel (8 East Coast trips/yr. @ $1200, 27,000
14 Western trips/yr. @ $600)
Foreign Travel (4 trips @ $2000) 8,000
Computer maintenance 60,000
Computer time costs 80,000
Other direct costs 40,000
---------
Subtotal 776,568
Indirect Costs (73% of above) 566,895
Capital equipment: 2 Sun 3/50MQ-8 Workstations 9,000
Capital equipment: 2 Fujitsu Eagle disk 12,000
Capital equipment: 4 processors, 1 cache, 32 meg.? 200,000
Lucid Subcontract 1,684,100
---------
Total 3,265,563
∂08-Feb-88 0942 CLT budget
To: IGS@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU
I can only think of two things
(1) We (Igor and I) discussed the possibility of
including a sysems person in the budget. Did
you decide against that?
(2) Our current computer charges are 11-12k per month
Some of that includes the non-qlisp personel that
are being charged to qlisp but if we actually hire
gosper and support 4 students it won't be much less than
9k unless we can find some free file storage.
Should we be realistic and bugdet for the actual
computer usage (162k rather than 80k for 18mo)?
∂08-Feb-88 1242 LIBRARY@Score.Stanford.EDU tech report overdue
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 12:42:36 PST
Date: Mon 8 Feb 88 12:37:34-PST
From: Math/Computer Science Library <LIBRARY@Score.Stanford.EDU>
Subject: tech report overdue
To: jmc@Sail.Stanford.EDU
cc: "*PS:<LIBRARY>OVERDUES..15"@Score.Stanford.EDU
Message-ID: <12373159947.31.LIBRARY@Score.Stanford.EDU>
STANFORD UNIVERSITY
MATH & COMPUTER SCIENCES LIBRARY
LIBRARY@SCORE
723-4672
_______________________________________________________________________________
DATE 2/8/88
CALL#: 24652
AUTHOR: Nelson and Oppen
TITLE: Simplification by cooperating design proced.
The above publication is overdue, and overdue notices have been sent
previously.
Renewable only in person with book.
PLEASE RETURN OR RENEW THIS TECH REPORT. If we do not hear from you by /88 we
will proceed with a replacement bill.
-------
∂08-Feb-88 1314 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU Software subcommittee report
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 13:14:10 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA02310; Mon, 8 Feb 88 13:14:39 PST
Date: Mon, 8 Feb 88 13:14:39 PST
From: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Message-Id: <8802082114.AA02310@nutmeg.Berkeley.EDU>
To: jmc@sail.stanford.edu
Subject: Software subcommittee report
Cc: ouster@nutmeg.Berkeley.EDU
Sorry to hound you, but you're the only member of the software
subcommittee of the "NAS Committee to Study ..." that I haven't
heard from at all with position statements for our report. Can
you tell me which of the following statements applies to you:
a) you've sent me your comments, so they must have gotten lost
in the mail if I didn't receive them (in this case could you
resend?);
b) you haven't had time to send me anything but are still planning
to provide some input (if so, could you let me know when I can expect
to receive something from you, preferably very soon?);
c) you don't plan to contribute to the software report (if so, could
you let me know so I don't wait around for your stuff?)
∂08-Feb-88 1409 ouster%nutmeg.Berkeley.EDU@Berkeley.EDU re: Software subcommittee report
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 14:09:04 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA02459; Mon, 8 Feb 88 14:09:32 PST
Date: Mon, 8 Feb 88 14:09:32 PST
From: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Message-Id: <8802082209.AA02459@nutmeg.Berkeley.EDU>
To: JMC@sail.stanford.edu
Subject: re: Software subcommittee report
OK, thanks for letting me know. I'll try to put together a draft
with what I've got.
∂08-Feb-88 1645 STAGER@Score.Stanford.EDU Re: industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:45:45 PST
Date: Mon 8 Feb 88 16:39:56-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Re: industrial lecturers
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 8 Feb 88 16:13:00-PST
Office: CS-TAC 29, 723-6094
Message-ID: <12373204071.9.STAGER@Score.Stanford.EDU>
Courses and Degrees copy is due on March 1. We can submit only minor changes
after that date.
Claire
-------
∂08-Feb-88 1658 LES re: QLISP budget draft
To: rivin@GANG-OF-FOUR.STANFORD.EDU
CC: JMC@SAIL.Stanford.EDU
[In reply to message sent Mon, 8 Feb 88 03:43:02 pst.]
The numbers I get from Bob Nikora are slightly better than my $200k
hand-wave. Including 20% educational discount, the prices are:
Price + Installation
4 CPU boards $105,600 + 1,240
32 MB memory 38,400 + 310
512 KB cache 20,000 + 310
================
$165,860
Curiously, their pricing makes buying the new cache and throwing away the
old 64 KB cache cheaper than upgrading -- they can't co-exist. There
would also be an increase in monthly maintenance charges -- I didn't get
that.
We seem to have no solid information about the extent to which cache
contention is a problem in the current system, but Gabriel's hand-wave is
that it is not. If it turned out to be a problem, you could buy another
512 KB cache.
∂08-Feb-88 2045 ZVONA%OZ.AI.MIT.EDU@AI.AI.MIT.EDU
Received: from OZ.AI.MIT.EDU (AI.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Feb 88 20:45:14 PST
Date: Mon, 8 Feb 1988 23:44 EST
Message-ID: <ZVONA.12373248657.BABYL@MIT-OZ>
From: David Chapman <ZVONA%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: jmc@SAIL.STANFORD.EDU
cc: zvona%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Hi... sorry this is so delayed; my thesis proposal deadline was Friday
and I was tied up this weekend. I hope this is still useful.
What I know is based on a conversation with Victor Segreyev, who is at
the USA Institute at the Arbatov. He does formal modeling of
political thinking, for example making "cognitive maps" of JFK's
belief system at various points during the Cuban missile crisis. His
work is similar to Schank's in flavor, though there seems not to be a
lot of direct connection.
He has one of apparently very few AI labs currently operating in the
USSR, and it is in the Economics department because the CS department
doesn't believe in AI. According to him, funding for AI is very
tight. On the one hand, the CS people think it's flakey nonsense, and
on the other the Marxist state philosophers think that Marxism is
incompatible with people being machines. The military actually wants
to fund AI, but (O wonderful irony!) they can't, because ALL research
money in Russia has to go through the Academy, which isn't interested.
Apparently this situation has been the case since Academician
proponents of AI all died in the late '70s. Up until then, AI was
counted as part of cybernetics, which of course the USSR had always
been strong on. A fair amount of what now counts as AI there is still
pretty cyberneticky -- "pattern analysis", e.g.
So since there is almost no official support of AI, the people who do
it all have backgrounds in something else and are part of some other
discipline. There are apparently a fair number of very hairy
mathematicians and physicists playing with it. They got connectionism
about two years ago and are heavily into it.
What I find most interesting is the connections with the Vygotsky
tradition of cognitive science. Vygotsky sort of plays the roles of
Piaget, Chomsky, and George Miller rolled into one in the Soviet
tradition. His work is very different from the western cognitive
science tradition; and, I think, much better. It was suppressed for
political reasons from about '30-'55, then there was a bunch of good
work done along his lines until the '70s, when it apparently went out
of political favor again. Lysenkoism. However, there's been a surge
of interest in it in the West in the last five/ten years (there's a
good summary by a guy called Wertsch called I think "Vygotsky and the
Social Formation of Mind") and some of it is getting translated.
Anyway, it turns out that there are a few people left working in this
tradition, and some of them are doing AI. These people seem to be
very smart (in particular, they recognize the very important
connections with the Sacks/Schegloff/Jefferson conversation analysis
program, which almost no one in the west recognizes). Unfortunately,
their work isn't translated.
It seems that there is work being done in almost all subareas of AI
over there. Segreyev left behind a recent summary collection volume;
it's in Russian, but he translated all the paper titles for us. They
have a bunch of vision work, mostly pattern analysis style, which is
presumably bogus. They have a lot of cognitive modeling, again of a
roughly Schankian variety, and presumably with the strengths and
weaknesses of Schankism. They have a bunch of NL processing stuff.
They have some robot arm work. There wasn't anything on theorem
proving or planning or that sort of thing, but I'd be surprised given
that a lot of their AI people are mathematicians if there wasn't some
work being done.
While we didn't talk about it in any detail, I got the impression that
the available computational resources are very poor; IBM PC level at
best.
The overall impression I have is that the (relatively few) people
doing AI there are very sharp, but that there is no coherent
leadership and no institutional support, so that the work they do is
spotty. But this is really based on relatively little talk with a guy
who doubtless has axes to grind within the Soviet Union and probably
also some impression he wants to leave with the Capitalists.
Hayward Alker, who is a professor in the Poli Sci department here, is
a friend of Segreyev's. He can probably tell you more than I. He
also has a stack of papers left behind by Segreyev; some his work and
some others'. Most are in Russian, but you might want to get the
abstracts of the rest translated. Alker is hralker@athena.mit.edu.
He doesn't read his mail much, so you might want to cc
rhhu@reagan.ai.mit.edu, who is one of his graduate students who
(nevertheless) works in this lab on NL stuff, and can (a) poke Hayward
and (b) probably also knows a fair bit about Soviet AI. Oh, yeah, you
could also call Alker: his number is (617)253-3642.
If you write something up about this, I'd be interested to see the
result.
Let me know if there's anything in this that you'd like me to expand
upon.
David
∂09-Feb-88 0220 rivin@Gang-of-Four.Stanford.EDU QLISP budget draft
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 02:19:59 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02306; Tue, 9 Feb 88 02:19:34 pst
Date: Tue, 9 Feb 88 02:19:34 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802091019.AA02306@Gang-of-Four.Stanford.EDU>
To: boesch@vax.darpa.mil
Subject: QLISP budget draft
Cc: jmc@sail, clt@sail
Here is a draft of the QLISP budget for the next 18 months. I hope it
has all the information you need. Perhaps it would, in any case, be
useful for us to discuss these matters further over the phone.
-- Igor Rivin
Proposal to DARPA
for
QLISP on Parallel Processors
Budget for the second 18 months
Personnel 18 Month Cost
Prof. John McCarthy (25% acad. yr., 50% Sum.) 47,087
William Gosper, Sr. Research Assoc. (100%) 90,000
Igor Rivin, Research Assoc. (100%) 72,216
Arkady Rabinov, Research Assoc. (100%) 83,214
Carolyn Talcott, Reseach Assoc. (50%) 40,842
Joe Weening, Research Assoc. (100%) 72,000
Dan Pehoushek, Research Programmer (100%) 43,506
Alex Gorbis, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
--------, Student Res. Assist. (50% acad. yr., 100% Sum.) 22,310
Pat Simmons, Secretary (50%) 15,993
---------
Salary Base 554,098
Allowance for salary increases 18,470
(5% beginning 9/1/88)
---------
Salary Total 572,568
Staff benefits (26.2% till 9/1/88, 153,448
27.1% thereafter)
Consultants (10 days/yr. @ $600) 6,000
Travel (8 East Coast trips/yr. @ $1200, 27,000
14 Western trips/yr. @ $600)
Foreign Travel (4 trips @ $2000) 8,000
Computer maintenance 60,000
Computer time costs 200,000
Other direct costs 40,000
---------
Subtotal 776,568
Indirect Costs (73% of above) 566,895
Capital equipment: 4 Sun 3/50MQ-8 Workstations 18,000
Capital equipment: 2 Fujitsu Eagle disk 12,000
Capital equipment: 4 processors, 1 cache, 32 meg. 165,860
Lucid Subcontract 1,684,100
---------
Total 3,360,423
∂09-Feb-88 1007 MPS Professor Lanzara
The professor called and would like to set up an appointment with
you this week or next (not Friday am). He said he wrote you a
letter. He is from Italy. Numbers are 415 321-2498(home) and
494-3704.
Pat
∂09-Feb-88 1030 VAL re: intro
[In reply to message rcvd 09-Feb-88 02:33-PT.]
As I understand your plan, you wanted to have an axiomatic theory in which we
can prove theorems of the form should-do(<immediate-action>). Do we have such
theories?
∂09-Feb-88 1037 VAL seminar
You said recently that you were planning to give a talk. Would you like to
do it this week?
∂09-Feb-88 1240 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: QLISP budget draft ]
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 12:40:26 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03992; Tue, 9 Feb 88 12:40:26 pst
Date: Tue, 9 Feb 88 12:40:26 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802092040.AA03992@Gang-of-Four.Stanford.EDU>
To: jmc@sail, clt@sail
Subject: [boesch@vax.darpa.mil: Re: QLISP budget draft ]
(I don't think he cc'd you...)
Return-Path: <boesch@vax.darpa.mil>
Posted-Date: Tue, 09 Feb 88 06:24:39 EST
To: Igor Rivin <rivin@gang-of-four.stanford.edu>
Subject: Re: QLISP budget draft
Cc: boesch@vax.darpa.mil
In-Reply-To: Your message of Tue, 09 Feb 88 02:19:34 -0800.
<8802091019.AA02306@Gang-of-Four.Stanford.EDU>
Date: Tue, 09 Feb 88 06:24:39 EST
From: boesch@vax.darpa.mil
Thanks, this can get me planning. I am glad that your estimate came
out about where mine (from the basic description you gave me at the
meeting) was.
There are two issues.
1. how to get you near term funding. For Stanford. (Lucid has about
$200k left over from last contract). We are working the possibility of
a short term grant of about $200 k to hold you over till I can get a
contract in place. Will know more in a few days.
2. Long term funding. This was left out of the budget for other than
this year (and was low for this year) so I have to work it. Things
may be a bit tight. (We may also be forced to delay or remove some of
the hardware to keep things down. But don't worry about that yet. I
need to do some planning.)
Please send me two text descriptions:
a. A description of a $200K effort (4-5 months)
b. A description of proposed work on the "contract" remaining of the
18 Months.
Look at old proposal to DARPA and update that with new budget and
tasks.
Thanks for the effort. If all goes well we may actually have this
figured out in a few days and hopefully get you back funded shortly.
Brian
∂09-Feb-88 1242 Qlisp-mailer meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 12:41:55 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03997; Tue, 9 Feb 88 12:41:59 pst
Date: Tue, 9 Feb 88 12:41:59 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802092041.AA03997@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: meeting
Is tomorrow (Wednesday) at noon in MJH352. The agenda will be current
business.
CUthere
Igor
∂09-Feb-88 1326 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
IDEAS ABOUT MENTAL SITUATION CALCULUS
John McCarthy
Stanford University
Friday, February 12, 3:15pm
MJH 301
Mental situation calculus involves mental actions and other
mental events affecting a mental situation. Mental situations are
more than just databases of beliefs, but contain also pedigrees of
the beliefs. This can permit formalizing "reason maintenance systems".
However, there is more, information about goals, for example. How
much more is far from clear. Formalized contexts come into the picture
as well as other kinds of intensional objects. The talk will present
a number of concepts and preliminary ideas about how they should
interact.
∂09-Feb-88 1332 VAL Tallinn
∂09-Feb-88 1325 meyer@THEORY.LCS.MIT.EDU [zucker@cs.Buffalo.EDU: COLOG-88: Preliminary Announcement]
Received: from THEORY.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 13:25:13 PST
Received: from STORK.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Tue, 9 Feb 88 14:12:57 est
Received: by STORK.LCS.MIT.EDU (4.12/4.7); Tue, 9 Feb 88 14:12:53 est
Date: Tue, 9 Feb 88 14:12:53 est
From: Albert R. Meyer <meyer@THEORY.LCS.MIT.EDU>
Message-Id: <8802091912.AA03351@STORK.LCS.MIT.EDU>
To: logic@THEORY.LCS.MIT.EDU
Subject: [zucker@cs.Buffalo.EDU: COLOG-88: Preliminary Announcement]
Date: Tue, 9 Feb 88 10:26:28 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@MITVMA.MIT.EDU>,
Jeffery Zucker <zucker@cs.Buffalo.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@MITVMA.MIT.EDU>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jeffery Zucker <zucker@cs.Buffalo.EDU>
Subject: COLOG-88: Preliminary Announcement
To: Local Distribution <THEORY@MC.LCS.MIT.EDU>
-------------------------------------------------------------------------
Preliminary announcement and call for papers
C O L O G - 88
INTERNATIONAL CONFERENCE ON COMPUTER LOGIC
December 12-16, 1988, Tallinn, Estonia, USSR
The aim of this conference is to establish scientific cooperation
in the field of computer logic. The presentation is in the form
of invited lectures (1 hour including discussion) and poster
sessions. Papers are invited in the following or related fields:
- applications of deductive systems
- dedctive program synthesis and analysis
- theorem proving
- computer experiments in logic-related fields
- logic programming
Chairman of the Program Committee is Per Martin-Lof (Sweden).
COLOG-88 will be held at the Institute of Cybernetics, Estonian
Academy of Sciences. Tallinn, old Hanseatic city, the capital of
Estonia, is situated at the Baltic Sea, 80 km from Helsinki, Finland,
and can be easily reached by boat from Helsinki.
Papers to be presented at poster sessions should arrive before
June 1, 1988, to
G. Mints
Institute of Cybernetics
Estonian Academy of Sciences
Akadeemia tee 21
Tallinn 200108
USSR
∂09-Feb-88 1503 helen@psych.Stanford.EDU Re: postpone lunch
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 15:03:13 PST
Received: by psych.Stanford.EDU (3.2/4.7); Tue, 9 Feb 88 15:01:21 PST
Date: Tue, 9 Feb 88 15:01:21 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: postpone lunch
Cc: helen@psych.Stanford.EDU
Hi there,
Well of the times you suggested, actually Saturday looks the best.
How does 1 p.m. Saturday sound?
-helen
∂09-Feb-88 1528 jcm@navajo.stanford.edu CS 258
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Feb 88 15:28:09 PST
Received: by navajo.stanford.edu; Tue, 9 Feb 88 15:24:09 PST
Date: Tue, 9 Feb 88 15:24:09 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: CS 258
To: ZM@sail.stanford.edu, jcm@navajo.stanford.edu, jmc@sail.stanford.edu,
pratt@navajo.stanford.edu
In writing up a quick list of topics that were
"not included," I meant not included in the
course I was proposing, and closely enough related
so that it might make sense to coordinate planning.
Sorry if I implied that something you are now teaching
is not being taught.
From lack of enthusiasm about MTC "planning in the large,"
I gather that is makes most sense for me to go ahead
with this course, and leave other planning matters go
until they seem more pressing.
John
Mitchell
∂09-Feb-88 1540 helen@psych.Stanford.EDU re: postpone lunch
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 15:39:55 PST
Received: by psych.Stanford.EDU (3.2/4.7); Tue, 9 Feb 88 15:38:04 PST
Date: Tue, 9 Feb 88 15:38:04 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: postpone lunch
Same place, in front of psych. I ALWAYS work on Saturdays these days!
Sound ok? See you then.
-helen
∂09-Feb-88 1654 BERGMAN@Score.Stanford.EDU new NSF grant
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 16:53:58 PST
Date: Tue 9 Feb 88 16:48:55-PST
From: Sharon Bergman <BERGMAN@Score.Stanford.EDU>
Subject: new NSF grant
To: jmc@Sail.Stanford.EDU, clt@Sail.Stanford.EDU
cc: bscott@Score.Stanford.EDU, bergman@Score.Stanford.EDU,
littell@Score.Stanford.EDU
Message-ID: <12373467850.50.BERGMAN@Score.Stanford.EDU>
John, Here is the information on your new NSF grant (title: "Research
in Mechanical Theorem Proving"):
Account no.: 2-DMA489
Fund no.: 163C895
NSF ref. no.: CCR-8718605
Amount: $172,351
Performance period: 1/1/88-12/31/88 (plus 6 mo. flexibility period)
-Sharon Bergman
-------
∂09-Feb-88 1857 Qlisp-mailer global variables in Qlisp (was: timing Qlisp programs)
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 18:56:53 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05272; Tue, 9 Feb 88 18:56:57 pst
Received: by labrea.Stanford.EDU; Tue, 9 Feb 88 18:56:52 PST
Received: from bhopal.lucid.com by edsel id AA03615g; Tue, 9 Feb 88 18:47:34 PST
Received: by bhopal id AA04682g; Tue, 9 Feb 88 18:52:17 PST
Date: Tue, 9 Feb 88 18:52:17 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802100252.AA04682@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
In-Reply-To: Jon L White's message of Sun, 7 Feb 88 19:12:18 PST <8802080312.AA14024@bhopal.lucid.com>
Subject: global variables in Qlisp (was: timing Qlisp programs)
Just so people know, we do intend to implement defglobalvar (and
defglobalparameter) that declare a variable to be global and will cause
the compiler to complain if an attempt is made to locally bind that variable.
I don't know if we plan on a function to get a variable's global value, but
something like symbol-global-value should be easy to do if we want it.
Ron
∂09-Feb-88 1930 Qlisp-mailer Re: global variables in Qlisp (was: timing Qlisp programs)
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 19:30:36 PST
Date: Tue, 9 Feb 88 19:29:41 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.Stanford.EDU>
Subject: Re: global variables in Qlisp (was: timing Qlisp programs)
To: edsel!arg@labrea.Stanford.EDU
cc: qlisp@sail.Stanford.EDU
In-Reply-To: <8802100252.AA04682@bhopal.lucid.com>
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12373497115.27.OKUNO@SUMEX-AIM.Stanford.EDU>
Is it true that compiler will produce codes to access a variable's
global value directly if the variable is declared as defglobalvar? If
yes, I don't need any special functions such as symbol-global-value.
(Such a function is needed to speed up interpretive execution as in
TAO.)
- Gitchang -
-------
∂10-Feb-88 0108 RDZ@Score.Stanford.EDU Party for John McCarthy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 01:08:16 PST
Date: Wed, 10 Feb 1988 01:02 PST
Message-ID: <RDZ.12373557739.BABYL@SCORE.STANFORD.EDU>
From: RDZ@Score.Stanford.EDU
To: jmc@Sail.Stanford.EDU, clt@Sail.Stanford.EDU, mps@Sail.Stanford.EDU,
rdz@Score.Stanford.EDU, jsw@Sail.Stanford.EDU,
rivin@Gang-of-Four.Stanford.EDU, val@Sail.Stanford.EDU,
nsh@Sail.Stanford.EDU, air@Sail.Stanford.EDU,
pehoushe@Gang-of-Four.Stanford.EDU, les@Sail.Stanford.EDU,
glb@Sail.Stanford.EDU, rpg@Sail.Stanford.EDU, jk@Sail.Stanford.EDU,
rwg@AI.AI.MIT.EDU, rww@Sail.Stanford.EDU
Subject: Party for John McCarthy
You are invited to attend a dinner party that will (somewhat
belatedly) welcome John McCarthy back to Stanford from his sabbatical
in Austin. The party will be held on Friday February 19, at 7:30, in
a restaurant to be anounced shortly. Spouses are also invited to this
gathering.
Please RSVP as soon as possible if you can make it, and tell me if you
will be bringing additional guests. We need to get a quick head-count
in order to make restaurant reservations.
Additional details will be forthcoming shortly.
Ramin Zabih
General Party Secretary
∂10-Feb-88 0944 Mailer re: Yet another flight to EastRidge Field...
Received: from umunhum.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Feb 88 09:44:30 PST
Received: by umunhum.stanford.edu; Wed, 10 Feb 88 09:41:13 PST
Date: Wed, 10 Feb 88 09:41:13 PST
From: Paul Flaherty <paulf@umunhum.stanford.edu>
Subject: re: Yet another flight to EastRidge Field...
To: JMC@sail.stanford.edu, paulf@umunhum.stanford.edu,
su-etc@sail.stanford.edu
As I understand it, the biggest problem is that the aircraft housed at
RH can't be housed anywhere else in the Bay Area...
-=paulf
∂10-Feb-88 1420 paulf@umunhum.stanford.edu Charlie Bass
Received: from umunhum.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Feb 88 14:19:58 PST
Received: by umunhum.stanford.edu; Wed, 10 Feb 88 14:16:45 PST
Date: Wed, 10 Feb 88 14:16:45 PST
From: Paul Flaherty <paulf@umunhum.stanford.edu>
Subject: Charlie Bass
To: jmc@sail.Stanford.EDU
Home: 408.353.2277
Work: 415.496.0111
Voice mail: 415.562.7995 x 1060
-=paulf
∂10-Feb-88 1932 Qlisp-mailer global variables in Qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 19:32:23 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00826; Wed, 10 Feb 88 19:32:25 pst
Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 19:32:20 PST
Received: from bhopal.lucid.com by edsel id AA08633g; Wed, 10 Feb 88 18:58:52 PST
Received: by bhopal id AA06547g; Wed, 10 Feb 88 19:03:40 PST
Date: Wed, 10 Feb 88 19:03:40 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802110303.AA06547@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
In-Reply-To: Hiroshi "Gitchang" Okuno's message of Tue, 9 Feb 88 19:29:41 PST <12373497115.27.OKUNO@SUMEX-AIM.Stanford.EDU>
Subject: global variables in Qlisp
In answer to your question, most definitely yes: a variable declared as a
defglobalvar will cause the compiler to generate code to directly access the
variable's value. Note that you can't bind such a variable, so the global
value is the same as the value. A function like SYMBOL-GLOBAL-VALUE would
be used to access the global value of a variable declared a defvar that
might have several bindings.
Ron
∂10-Feb-88 1959 Qlisp-mailer new-qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 19:59:24 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00977; Wed, 10 Feb 88 19:59:27 pst
Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 19:59:19 PST
Received: from kolyma.lucid.com by edsel id AA08879g; Wed, 10 Feb 88 19:49:17 PST
Received: by kolyma id AA02998g; Wed, 10 Feb 88 19:56:55 PST
Date: Wed, 10 Feb 88 19:56:55 PST
From: Carol Sexton <edsel!carol@labrea.Stanford.EDU>
Message-Id: <8802110356.AA02998@kolyma.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp
I've just installed a new-qlisp (and shortly thereafter found a few bugs in it).
This lisp checks a bit when accessing and setting symbol values.
This bit indicates whether or not a special has ever been bound.
If the special hasn't been bound, the symbol-value is fetched from
the global value cell of the symbol rather than searching up the stack for
the last dynamic binding. This change speeds up code which has specials
but never binds them and slows down code which binds specials.
This lisp also includes an initial implementation of defglobalvar.
There are some new functions and macros - defglobalvar, defglobalparameter, and
globalp.
Defglobalvar declares a variable to be global and treats its arguments like
defvar. Defglobalparameter declares a variable to be global and treats
its arguments like defparameter.
The predicate globalp is true of an object if the object is a global variable.
Let me know of any bugs related to this stuff.
I know of a few bugs already which I hope to fix tonight.
The previous new-qlisp is in /lucid/bin/new-qlisp.save. New-qlisp.save will disappear
as soon as the new new-qlisp stablizes.
Carol
∂10-Feb-88 2000 JMC
bass
∂10-Feb-88 2251 @Score.Stanford.EDU,@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU,@MC.LCS.MIT.EDU:lusk@anl-mcs.ARPA CADE-9 registration info and preliminary schedule
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 22:51:14 PST
Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 22:45:51-PST
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Thu 11 Feb 88 01:42:51-EST
Received: from anl-mcs.ARPA (TCP 3200200067) by MC.LCS.MIT.EDU 11 Feb 88 01:23:40 EST
Received: by anl-mcs.ARPA (4.12/4.9)
id AA00376; Wed, 10 Feb 88 17:20:02 cst
Date: Wed, 10 Feb 88 17:20:02 cst
From: lusk@anl-mcs.ARPA (Rusty Lusk)
Message-Id: <8802102320.AA00376@anl-mcs.ARPA>
To: aiout@anl-mcs.ARPA
Subject: CADE-9 registration info and preliminary schedule
CADE - 9
9th International Conference on Automated Deduction
May 23-26, 1988
Preliminary Schedule and Registration Information
CADE-9 will be held at Argonne National Laboratory (near Chicago) in cele-
bration of the 25th anniversary of the discovery of the resolution princi-
ple at Argonne in the summer of 1963.
Dates
Tutorials: Monday, May 23
Conference: Tuesday, May 24 - Thursday, May 26
Main Attractions:
1. Presentation of more than sixty papers related to aspects of automated
deduction. (A detailed listing of the papers is attached.)
2. Invited talks from
Bill Miller, president, SRI International
J. A. Robinson, Syracuse University
Larry Wos, Argonne National Laboratory
all of whom were at Argonne 25 years ago when the resolution principle
was discovered.
3. Organized dinners every night, including the Conference banquet,
"Dinner with the Dinosaurs", at Chicago's Field Museum of Natural His-
tory.
4. Facilities for demonstration of and experimentation with automated
deduction systems.
5. Tutorials in a number of special areas within automated deduction.
Tutorials:
We have tried to make the tutorials relatively short and inexpensive. It
is hoped that many researchers that are skilled in specialized areas of
automated deduction will take the opportunity to get an overview of related
research areas. Some of the details (like titles, exactly which member of
a team will give the tutorial, etc.) have not yet been finalized. The fol-
lowing information reflects our current information. It may change
slightly, but expect that no major changes will occur.
Tutorial 1: Constraint Logic Programming
This will be a tutorial on the Constraint Logic Programming Scheme,
and systems that have implemented the concepts (see "Constraint Logic
Programming", J. Jaffar and J-L Lassez, Proc. POPL87, Munich, January
1987).
Tutorial 2: Verification and Synthesis
This will be a tutorial by Zohar Manna and Richard Waldinger on their
work in verification and synthesis of algorithms.
Tutorial 3: Rewrite Systems
This will be a tutorial given by Mark Stickel covering the basic ideas
of equality rewrite systems.
Tutorial 4: Theorem Proving in Non-Standard Logics
This tutorial will be given by Michael McRobbie. It will cover a
number of topics from his new book.
Tutorial 5: Implementation I: Connection Graphs
This tutorial will be given by members of the SEKI project. It will
cover issues concerning why connections graphs are used and how they
can be implemented.
Tutorial 6: Implementation II: an Argonne Perspective
This tutorial will present the central implementation issues from the
perspective of a number of members of the Argonne group. It will
cover topics like choice of language, indexing, basic algorithms, and
utilization of multiprocessors.
Tutorial 7: Open questions for Research
This tutorial will be given by Larry Wos. It will focus on two col-
lections of open questions. One set consists of questions about the
field of automated theorem proving itself, questions whose answers
will materially increase the power of theorem-proving programs. The
other set consists of questions taken from various fields of mathemat-
ics and logic, questions that one might attack with the assistance of
a theorem-proving program. Both sets of questions provide intriguing
challenges for possible research.
How to Register
Fill out the following registration form (the part of this message between
the rows of ='s) and return as soon as possible to:
Mrs. Miriam L. Holden, Director
Conference Services
Argonne National Laboratory
9700 South Cass Avenue
Argonne, IL 60439
U. S. A.
Questions relating to registration and accommodations can be directed to
Ms. Miriam Holden or Joan Brunsvold at (312) 972-5587.
!
============================================================================
9th International Conference on Automated Deduction
May 23-26, 1988
Argonne National Laboratory
Argonne, Illinois, USA
Registration Form
(please print or type)
Name_________________________________________________________________________
(First) Middle) (Last)
Organization_________________________________________________________________
Business Address_____________________________________________________________
(Street) (City) (State) (Zip)
Business Phone_____________________Citizenship_______________________________
Electronic mail______________________________________________________________
_____________________________________________________________________________
Registration Fees
Nonstudent Student
Registration $180.00 __ $75.00 __
One Tutorial 50.00 __ 30.00 __
Two Tutorials 75.00 __ 40.00 __
Three Tutorials 90.00 __ 50.00 __
Two Optional Meals 40.00 __ 40.00 __
Total Enclosed: ____________________
Note: Checks ($U.S. dollars) must be made payable to Argonne National
Laboratory. (No credit cards accepted)
_____________________________________________________________________________
Housing
I would like accommodations for the NIGHTS of May____ through ____, 1988.
__ Willowbrook Holiday Inn __ Budgetel
7800 South Kingery Highway __ 855 79th Street
Willowbrook, IL 60521 Willowbrook, IL 60521
(312) 325-6400 (312) 654-0077
__ Single ($54.57/night) __ Single ($33.66/night)
__ Double ($65.27/night) __ Double ($39.44/night)
__ Name of Second Occupant________________________________________
__ No housing accommodations required
Rooms will be reserved on guaranteed basis. If you have a change in plans,
please advise us to cancel your reservation or call the Holiday Inn or
Budgetel.
___________________________________________________________________________
!
___________________________________________________________________________
Social Functions
I plan to attend:
__ Dinner at Carriage Greens Country Club on Monday, May 23.
(included in registration fee)
__ Dinner at Memories of China Restaurant in Chicago on Tuesday, May 24
__ "Dinner with Dinosaurs" Banquet at Field Museum on Wednesday, May 25
(Dinner on May 24 and Banquet on May 25 are both included in the
optional meals fee - see above.)
____________________________________________________________________________
Transportation
Both O'Hare and Midway airports are about a 45-minute car trip from Argonne
and the hotels. Limousine service can be arranged (at your expense) with
Travelers Limousine from either airport at a cost of $19.00/person plus
$4.00 for each additional person in the car. If you would like us to
arrange the limousine service for you, please complete:
I will arrive on ________________ at _______________ on ___________ airline
Flight number ______________________ from __________________ (city & state)
Chartered bus service will provide transportation to and from the confer-
ence site each day and to and from the arranged dinner each night.
===========================================================================
Please return this form with your check to:
Mrs. Miriam L. Holden, Director
Conference Services
Argonne National Laboratory
9700 South Cass Avenue
Argonne, IL 60439
U. S. A.
Preliminary Conference Schedule
Monday, May 23
_________________________________________________________________________
TUTORIALS
slot 1 slot 2 slot 3
9 - 11:30 Constraint Logic Prog. Verification --
12:30 - 3 Rewrite systems Theorem-proving Implementation I
in non-standard
logics
3:30 - 6 Open problems -- Implementation II
__________________________________________________________________________
6:30-7 Cocktails at Carriage Green
7-9 Dinner at Carriage Green
Tuesday, May 24
8:30-9 Coffee/welcome
9-10 Invited talk by William Miller of SRI
10-10:30 Coffee
10:30-12 Sessions 1 and 2
1:20-2:20 Sessions 3 and 4
2:20-3 Coffee
3-4 Sessions 5 and 6
4-4:30 Coffee
4:30-5:30 Sessions 7 and 8
7:30 Dinner at House of Hunan in Chicago (optional meal)
_________________________________________________________________________
Wednesday, May 25
8:30-9 Coffee
9-10:30 Sessions 9 and 10
10:30-11 Coffee
11-12 Sessions 11 and 12
1:30-2:30 Invited talk by J.A. Robinson
"How Machine-Oriented Might a Logic Be?"
2:30-9 Time in Chicago/Banquet at Field Museum (optional meal)
banquet speaker will be Larry Wos:
"A Review of the First 25 Years of Automated
Theorem Proving, and a Prediction Concerning
the Next 25 Years"
__________________________________________________________________________
Thursday, May 25
8:30-9 Coffee
9-10:00 Sessions 13 and 14
10-10:30 Coffee
10:30-12 Sessions 15 and 16
1:20-2:20 Sessions 17 and 18
2:20-3 Coffee
3-4 Sessions 19 and 20
4-4:30 Coffee
4:30-5:30 Sessions 21 and 22
_________________________________________________________________________
Preliminary Session Schedule
Session 1
First-Order Theorem Proving Using Conditional Rewriting
Hantao Zhang
Deepak Kapur
Elements of Z-Module Reasoning
T.C. Wang
Session 2
Flexible Application of Generalised Solutions Using Higher Order Resolution
Michael R. Donat
Lincoln A. Wallen
Specifying Theorem Provers in a Higher-Order Logic Programming Language
Amy Felty
Dale Miller
Query Processing in Quantitative Logic Programming
V. S. Subrahmanian
Session 3
An Environment for Automated Reasoning About Partial Functions
David A. Basin
The Use of Explicit Plans to Guide Inductive Proofs
Alan Bundy
LOGICALC: an environment for interactive proof development
D. Duchier
D. McDermott
Session 4
Implementing Verification Strategies in the KIV-System
M. Heisel
W. Reif
W. Stephan
Checking Natural Language Proofs
Donald Simon
Consistency of Rule-based Expert Systems
Marc Bezem
Session 5
A Mechanizable Induction Principle for Equational Specifications
Hantao Zhang
Deepak Kapur
Mukkai S. Krishnamoorthy
Finding Canonical Rewriting Systems Equivalent to a Finite Set of
Ground Equations in Polynomial Time
Jean Gallier
Paliath Narendran
David Plaisted
Stan Raatz
Wayne Snyder
Session 6
Towards Efficient Knowledge-Based Automated Theorem Proving for
Non-Standard Logics
Michael A. McRobbie
Robert K. Meyer
Paul B. Thistlewaite
Propositional Temporal Interval Logic is PSPACE
A. A. Aaby
K. T. Narayana
Session 7
Computational Metatheory in Nuprl
Douglas J. Howe
Type Inference and Its Applications in Prolog
H. Azzoune
Session 8
Procedural Interpretation of Non-Horn Logic Programs
Arcot Rajasekar
Jack Minker
Recursive Query Answering with Non-Horn Clauses
Shan Chi
Lawrence J. Henschen
Session 9
Case Inference in Resolution-Based Languages
T. Wakayama
T.H. Payne
Notes on Prolog Program Transformations, Prolog Style, and Efficient
Compilation to the Warren Abstract Machine
Ralph M. Butler
Rasiah Loganantharaj
Exploitation of Parallelism in Prototypical Deduction Problems
Ralph M. Butler
Nicholas T. Karonis
Session 10
A Decision Procedure for Unquantified Formulas of Graph Theory
Louise E. Moser
Adventures in Associative-Commutative Unification (A Summary)
Patrick Lincoln
Jim Christian
Unification in Finite Algebras is Unitary(?)
Wolfram Buttner
Session 11
Unification in a Combination of Arbitrary Disjoint Equational Theories
Manfred Schmidt-Schauss
Partial Unification for Graph Based Equational Reasoning
Karl Hans Blasius
Jorg Siekmann
Session 12
SATCHMO: A theorem prover implemented in Prolog
Rainer Manthey
Francois Bry
Term Rewriting: Some Experimental Results
Richard C. Potter
David Plaisted
Session 13
Analogical Reasoning and Proof Discovery
Bishop Brock
Shaun Cooper
William Pierce
Hyper-Chaining and Knowledge-Based Theorem Proving
Larry Hines
Session 14
Linear Modal Deductions
L. Farinas del Cerro
A. Herzig
A Resolution Calculus for Modal Logics
Hans Jurgen Ohlbach
Session 15
Solving Disequations in Equational Theories
Hans-Jurgen Burckert
On Word Problems in Horn Theories
Emmanuel Kounalis
Michael Rusinowitch
Canonical Conditional Rewrite Systems
Nachum Dershowitz
Mitsuhiro Okada
G. Sivakumar
Program Synthesis by Completion with Dependent Subtypes
Paul Jacquet
Session 16
Reasoning about Systems of Linear Inequalities
Thomas Kaufl
A Subsumption Algorithm Based on Characteristic Matrices
Rolf Socher
A Restriction of Factoring in Binary Resolution
Arkady Rabinov
Supposition-Based Logic for Automated Nonmonotonic Reasoning
Philippe Besnard
Pierre Siegal
Session 17
Argument-Bounded Algorithms as a Basis for Automated Termination Proofs
Christoph Walther
Automated Aids in Implementation Proofs
Leo Marcus
Timothy Redmond
Session 18
A New Approach to Universal Unification and Its Application to AC-Unification
Mark Franzen
Lawrence J. Henschen
An Implementation of a Dissolution-Based System Employing Theory Links
Neil V. Murray
Erik Rosenthal
Session 19
Decision Procedure for Autoepistemic Logic
Ilkka Niemela
Logical Matrix Generation and Testing
Peter K. Malkin
Errol P. Martin
Optimal Time Parallel Algorithms for Term Matching
Rakesh M. Verma
I.V. Ramakrishnan
Session 20
Challenge Equality Problems in Lattice Theory
William McCune
Single Axioms in the Implicational Propositional Calculus
Frank Pfenning
Challenge Problems Focusing on Equality and Combinatory Logic:
Evaluating Automated Theorem-Proving Programs
Larry Wos
William McCune
Challenge Problems from Nonassociative Rings for Theorem Provers
Rick Stevens
∂11-Feb-88 0908 MPS Omni Magazine
Good Morning
Mike Liebowitz (617 734-9115) is doing an article for
the above magazine on the CYC project and would like
our comments and criticisms on it. Doug Lenat fits into
the picture somehow and I could not figure out how.
Pat
∂11-Feb-88 0944 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 09:44:12 PST
Date: Thu 11 Feb 88 09:37:51-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12373913665.19.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
February 12: Dr. Leslie Lamport (DEC-SRC),
"What Good is Temporal Logic?"
February 19: Dr. Luca Cardelli (DEC-SRC),
"A Gentle Introduction to Intuitionistic Type Theory"
-------
∂11-Feb-88 1119 VAL phil.tex[ess,jmc]
That file is TeXed only at the beginning. Is there a version fully in TeX?
∂11-Feb-88 1504 RPG Point of Fact
Which year would *you* consider the 30th anniversary of
Lisp? Is 1989 a reasonable year?
-rpg-
∂11-Feb-88 1540 Mailer re: James Bond question
To: JMC@SAIL.Stanford.EDU, su-etc@SAIL.Stanford.EDU
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
[In reply to message sent Mon, 8 Feb 88 22:14:41 PST.]
I understand some aircraft let you see the instrument panel
projected by reflection to the horizon in front of you. I
wish that were available in cars. I can read the radio
frequency by reflection (electronic tuning) and that makes me
somewhat less dangerous.
∂11-Feb-88 1617 VAL The 1980 circ'n paper
MINIMA[S77,JMC] isn't in TeX. Is it possible that we don't have a TeXed version
of that paper?
∂12-Feb-88 0039 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
IDEAS ABOUT MENTAL SITUATION CALCULUS
John McCarthy
Stanford University
Friday, February 12, 3:15pm
MJH 301
Mental situation calculus involves mental actions and other
mental events affecting a mental situation. Mental situations are
more than just databases of beliefs, but contain also pedigrees of
the beliefs. This can permit formalizing "reason maintenance systems".
However, there is more, information about goals, for example. How
much more is far from clear. Formalized contexts come into the picture
as well as other kinds of intensional objects. The talk will present
a number of concepts and preliminary ideas about how they should
interact.
∂12-Feb-88 0133 rivin@Gang-of-Four.Stanford.EDU Is that what Boesh wants, do you think?
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 01:32:58 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04924; Fri, 12 Feb 88 01:32:52 pst
Date: Fri, 12 Feb 88 01:32:52 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802120932.AA04924@Gang-of-Four.Stanford.EDU>
To: jmc@sail, clt@sail
Cc: rpg@sail
Subject: Is that what Boesh wants, do you think?
This is an extension of the original bullets I prepared. An obvious
difference is that the next eighteen months period is now split in two
parts, as per Boesch's request. Also, some things have been added, and
it is somewhat more detailed. Comments/suggestions are solicited
before I actually fire it off.
A related point about Boesch's email, is that he mentions a $200K
amount to tide us (Stanford) over the 4-5 months. Try as I might, I
cannot see any easy way for this to happen -- simply pro-rating our proposed
18 months figure gives about $100K a month burn rate, and even
deleting Gosper and Joe, who are not on the payroll yet, and hardware
upgrades, which can (I suppose) be postponed till the second 14(?)
months, still doesn't bring us sufficiently close to $200K figure.
Maybe there is something I don't understand, however (more than likely).
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
This has been proceeding at a good pace, after some intial delay
setting up the Stanford-Lucid computer link
o Lucid Common Lisp has been implemented (March 87)
o QLET T has been implemented (July 87)
o QLAMBDA T has been implemented (December 87)
o Several convenient locking primitives have been designed and
implemented (December 87)
o Dynamic variables have been implemented using the deep binding
strategy (January 88)
o Several task-scheduling algorithms have been implemented and tested
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
QLISP programs have been showing speedups of greater than 3x on the
four processors we have. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
The Lisp programs implemented started from "toy" examples, such as
Fibonacci, then progressing to implementations of original parallel
algorithms for sorting, to implementing some of the Gabriel
benchmarks (Boyer, Tak), to polynomial arithmetic to fairly
sophisticated computer algebra problems (univariate polynomial
Greatest Common Divisor), as the Qlisp implementation has grown
more robust.
In the current Lucid implementation, it takes about .3 milliseconds
to spawn a process, so as long as the granularity of a problem is
considerably greater
than that, good speedups can reasonably be expected. The number of
active processes should be no more than around a thousand and certainly
no less than the number of processors in order for reasonable speedups to
be achievable. In many of the applications below, these conditions have
been met.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming.
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort (August
87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented (December 1987)
The Next Eighteen Months (the dates below are targets for completion, work
is predicated on the proposed increased (a) and originally requested (b)
levels of funding)
oo QLISP implementation on the Alliant FX/8 (mini-contract for next
4-5 months)
o Non-local exits via CATCH and THROW will be implemented (March 88)
o The implementation of deep binding will be improved
o Bugs in the underlying Lisp caused by multiprocessing will be fixed
(April 88)
o Some simple debugging tools will be implemented (July 88)
o The 'EAGER forms of QLET and QLAMBDA will be implemented (June 88)
o The EAGER forms of QLET and QLAMBDA constructs will be implemented
(June 88)
oo Application Development (mini-contract)
o The present Computer Algebra effort will continue. Next on
our agenda are a parallel implemetation of Hensel's lemma and of
multivariate polinomial Greatest Common Divisor algorithms
o A reference manual for Qlisp will be produced (May 88)
oo QLISP implementation on the Alliant FX/8 (the remainder of the 18
months)
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed. (September 88)
o Better performance-monitoring tools will be designed. (September
88)
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan)
(January 89)
o A more usable program development environment will be designed.
(prototype system by March 89)
oo Applications Development (remainder of 18 months)
Experiments will be conducted with implementing medium-to-large
systems.
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place (Continuous through
duration of contract).
o Other application domains in symbolic processing will be investigated
(continuous)
o A Qlisp User's Guide for the benefit of the research community will be
produced (first draft by January 89)
oo Ports to Other Hardware
The Alliant FX/8 is limited both in computing power (at most
eight processors) and in generality of code written for it (the
code is likely to not be easy to port to other multiprocessors).
These problems will be addressed.
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having QLISP
available on other machines will make it more widely available to
experimentation by DARPA research community
o Porting to Encore under MACH will be evaluated (by August 88)
o Distributed extensions under MACH will be evaluated (by January 89)
o Multitasking will be evaluated under MACH, so that parallel programs
can be run on uniprocessors. (by January 89)
∂12-Feb-88 0250 rivin@Gang-of-Four.Stanford.EDU next week
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 02:37:47 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04979; Fri, 12 Feb 88 02:37:46 pst
Date: Fri, 12 Feb 88 02:37:46 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802121037.AA04979@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: next week
I will be visiting David Mumford at Harvard and Bill Thurston at Princeton
and some lesser mathematicians at various eastern universities
(Columbia, IAS, BU, etc)
Quite likely some geometric algorithms suitable for Qlisp
implementation will ensue.
In any case, I will be in constant electronic and, if need be, phone
contact.
Igor
PS: I know I should have planned a bit further in advance, but
this was arranged at rather short notice...
∂12-Feb-88 1134 VAL two puzzles
I left a draft on your terminal. Please tell me if we want to make any major
changes in it. The same question about the Mr. Hug paper.
∂12-Feb-88 1151 PMACLIN%UTMEM1.BITNET@forsythe.stanford.edu your Daedelus paper
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 12 Feb 88 11:51:08 PST
Received: by lindy.stanford.edu; Fri, 12 Feb 88 11:52:20 PST
Received: by Forsythe.Stanford.EDU; Fri, 12 Feb 88 11:50:45 PST
Date: Fri, 12 Feb 88 13:31 CST
From: <PMACLIN%UTMEM1.BITNET@forsythe.stanford.edu>
Subject: your Daedelus paper
To: jmc@sail.stanford.edu
X-Original-To: jmc@sail.stanford.edu, PMACLIN
I read with interest your "Two Extreme Approaches to AI" on AIList. If
possible, I would appreciate it if you could send me a copy of your Daedalus
paper and any other of your key papers on AI. Although I have been studying AI
for two years, I am still rather a novice. Thanks.
Philip Maclin
Computer Science Dept.
Univ. of Tennessee at Memphis
877 Madison Ave.
Memphis, TN 38163
Phone 901 528-5848
PMACLIN@UTMEM1
∂12-Feb-88 1351 P.PROMETHEUS@HAMLET.STANFORD.EDU honors project/CSLI internship
Received: from HAMLET.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 13:51:27 PST
Date: Fri 12 Feb 88 13:45:45-PST
From: Reid Hoffman <P.PROMETHEUS@HAMLET.STANFORD.EDU>
Subject: honors project/CSLI internship
To: jmc@SAIL.STANFORD.EDU
Message-ID: <12374220936.110.P.PROMETHEUS@HAMLET.STANFORD.EDU>
If you would prefer not to meet with me, please send me a note to that effect.
thanks,
reid
-------
∂12-Feb-88 1403 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
Received: from HAMLET.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 14:03:47 PST
Date: Fri 12 Feb 88 13:58:00-PST
From: Reid Hoffman <P.PROMETHEUS@HAMLET.STANFORD.EDU>
Subject: re: honors project/CSLI internship
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 12 Feb 88 13:54:00-PST
Message-ID: <12374223168.110.P.PROMETHEUS@HAMLET.STANFORD.EDU>
I sent you (perhaps too long of) a letter detailing four different topics in AI
which I might wish to do honors projects in--mostly stuff in the history and
philosophy of AI. (I am planning a second honors project with programming an AI
system next year.) I was wondering if you would have time to meet with me, and
perhaps direct me to some sources of material.
Second, I would like to work at Stanford this summer with a CSLI internship,
and was wondering if you might be interesting in sponsoring a project (perhaps
related to my honors work.)
Lastly, I am contemplating making some of your work/ideas focal points in some
chapters in my honors thesis, and I was wondering if I could either meet with
you or perhaps see some of your papers on the subjects.
thaks
reid
-------
∂12-Feb-88 1409 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
Received: from HAMLET.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 14:09:34 PST
Date: Fri 12 Feb 88 14:03:49-PST
From: Reid Hoffman <P.PROMETHEUS@HAMLET.STANFORD.EDU>
Subject: re: honors project/CSLI internship
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 12 Feb 88 14:06:00-PST
Message-ID: <12374224226.110.P.PROMETHEUS@HAMLET.STANFORD.EDU>
Sorry, I need to finish a complicated C program by this evening, and I am
currently far away from Stanford. Could we meet next week?
Also, CSLI funds my salary for the internship. There would be no financial
burden on you.
thanks
reid
-------
∂12-Feb-88 1417 P.PROMETHEUS@HAMLET.STANFORD.EDU re: honors project/CSLI internship
Received: from HAMLET.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 14:17:31 PST
Date: Fri 12 Feb 88 14:11:34-PST
From: Reid Hoffman <P.PROMETHEUS@HAMLET.STANFORD.EDU>
Subject: re: honors project/CSLI internship
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 12 Feb 88 14:11:00-PST
Message-ID: <12374225637.110.P.PROMETHEUS@HAMLET.STANFORD.EDU>
Ok. I'll try either monday later afternoon (circa 4:30), or tuesday late
afternoon, or sometime thur.
thanks
reid
-------
∂12-Feb-88 1600 L.LARSSON@MACBETH.STANFORD.EDU re: honors project/CSLI internship
Received: from MACBETH.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 16:00:09 PST
Date: Fri 12 Feb 88 15:55:00-PST
From: Reid Hoffman <P.PROMETHEUS@MACBETH.STANFORD.EDU>
Subject: re: honors project/CSLI internship
Sender: L.LARSSON@MACBETH.STANFORD.EDU
To: JMC@SAIL.STANFORD.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 12 Feb 88 14:22:00-PST
Message-ID: <12374244466.206.L.LARSSON@MACBETH.STANFORD.EDU>
I'll try to make it at 2. Thanks
reid
-------
∂12-Feb-88 1615 JSW Alliant & Symbolics
To: LES@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU,
CLT@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU
Who should be handling negotiations with Alliant and Symbolics? In the
near future we need to deal with the following issues:
Alliant:
> Loan of the extra 4 processors (and extra cache?)
> Renewal of maintenance agreement (in May?)
> Possible purchase of extra hardware
> Purchase of Ada compiler, if Wiederhold/Keller project makes use
of the machine. They'd like to know at this point how much Ada
will cost.
Symbolics:
> Addition of Eagle disk to hardware maintenance (immediately)
> Renewal of hardware and software maintenance (June or July)
> Statement of interest in multiprocessor
> Possible purchase of multiprocessor for Qlisp
Some of these things, especially the Symbolics disk maintenance and
statement of interest in the multiprocessor, should be done as soon
as possible.
∂13-Feb-88 1218 helen@psych.Stanford.EDU Have you forgotten something?
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 12:17:55 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sat, 13 Feb 88 12:15:46 PST
Date: Sat, 13 Feb 88 12:15:46 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Have you forgotten something?
I've been waiting outside Jordan Hall since noon. Remember we have
lunch today? I'll head back down there now and hang out for another
15 minutes just in case. Then I'll head to a place called Caffe Verona
on Hamilton ave. in downtown P.A. It's in the block just south of
the City Government building. Drop by if you read this in time!
-helen
∂13-Feb-88 1228 helen@psych.Stanford.EDU Oops, sorry
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 12:28:17 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sat, 13 Feb 88 12:26:07 PST
Date: Sat, 13 Feb 88 12:26:07 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Oops, sorry
I just remembered our date is for 1 p.m. not noon. Sorry about that...
I'll be here (out front) at 1 p.m. as agreed!
-helen
∂13-Feb-88 1655 helen@psych.Stanford.EDU Party Info!
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:55:43 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sat, 13 Feb 88 16:53:31 PST
Date: Sat, 13 Feb 88 16:53:31 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Party Info!
Cc: helen@psych.Stanford.EDU
John,
Here are the directions. I'm still looking for Ilan so will get back
to you ASAP. Bye for now!
-helen
---------------
Party with music by the Wizards
50's & 60's rock 'n' roll (real dance music!)
Saturday night, February 13th -- party starts at 8,
music at 9, goes until everyone leaves...
at 121 Escanyo Way, Ladera, Tel: (415) 854-1473
the house of Bertrand, Greg, Jeff, Mark and Carolyn (special guest)
Bring friends and drinks.
Take Alpine Road going towards Portola Valley. Just past the little shopping
center, make a right on LA MESA. Continue on LA MESA until ERICA. Take left
on ERICA until you reach your first left which will be ESCANYO Way. The house
is the second house on the left. You can't see the house from the street,
just a steep driveway.
See you there,
Ron
------------
∂13-Feb-88 1843 helen@psych.Stanford.EDU Tonight: plans
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 18:43:29 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sat, 13 Feb 88 18:41:16 PST
Date: Sat, 13 Feb 88 18:41:16 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Tonight: plans
Cc: helen@psych.Stanford.EDU
Hi there,
Well I found vardi and we are planning to leave from the psych
dept at 9 p.m. Would you like to meet us in front of psych at
9 p.m.? We have motorcycles so I guess we can decide at that
time whether it is preferable to ride together in your car or
simply 'caravan'. I'll check my mail again around 9 for your
reply (a bit before 9 that is). See you later!
-helen
∂14-Feb-88 1119 mcvax!inria.inria.fr!queinnec@uunet.UU.NET re: IWoLES
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:19:11 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA21305; Sun, 14 Feb 88 14:19:19 EST
Received: by mcvax.cwi.nl; Sun, 14 Feb 88 20:15:16 +0100 (MET)
Received: by inria.inria.fr; Sun, 14 Feb 88 20:10:08 +0100 (MET)
Date: Sun, 14 Feb 88 20:10:08 +0100
From: mcvax!inria.inria.fr!queinnec@uunet.UU.NET (Christian Queinnec)
Message-Id: <8802141910.AA29987@inria.inria.fr>
To: JMC@sail.stanford.edu
Subject: re: IWoLES
I acknowledge the receipt of your text. I was on hollidays last week.
C.Queinnec
∂14-Feb-88 1158 rivin@Gang-of-Four.Stanford.EDU Alliant & Symbolics
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:57:57 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00718; Sun, 14 Feb 88 11:57:48 pst
Date: Sun, 14 Feb 88 11:57:48 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802141957.AA00718@Gang-of-Four.Stanford.EDU>
To: JSW@SAIL.Stanford.EDU
Cc: LES@SAIL.Stanford.EDU, IGS@SAIL.Stanford.EDU, CLT@SAIL.Stanford.EDU,
JMC@SAIL.Stanford.EDU
In-Reply-To: Joe Weening's message of 12 Feb 88 1615 PST <8802130015.AA06577@Gang-of-Four.Stanford.EDU>
Subject: Alliant & Symbolics
Date: 12 Feb 88 1615 PST
From: Joe Weening <JSW@SAIL.Stanford.EDU>
Who should be handling negotiations with Alliant and Symbolics? In the
near future we need to deal with the following issues:
Alliant:
> Loan of the extra 4 processors (and extra cache?)
I will call them on tuesday
> Renewal of maintenance agreement (in May?)
Ditto
> Possible purchase of extra hardware
Unclear in how near a future will this be feasible given our
budgetary woes.
> Purchase of Ada compiler, if Wiederhold/Keller project makes use
of the machine. They'd like to know at this point how much Ada
will cost.
I will check the pricing on tuesday, certainly there is neither point
nor funds in rushing out to buy it for the next several months.
Symbolics:
> Addition of Eagle disk to hardware maintenance (immediately)
I am not sure that this can be done until the no-cost extension is
formally approved. In view of the relatively low cost this should be
done as soon as possible, however (this=getting the maintenance).
> Renewal of hardware and software maintenance (June or July)
> Statement of interest in multiprocessor
I will attempt to draw one up. I assume JMC will need to actually sign it.
> Possible purchase of multiprocessor for Qlisp
This is surrounded my multiple question marks, especially in view of
the last missive from Boesch (which I will forward momentarily)
Some of these things, especially the Symbolics disk maintenance and
statement of interest in the multiprocessor, should be done as soon
as possible.
∂14-Feb-88 1317 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: QLISP budget draft ]
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:17:36 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00861; Sun, 14 Feb 88 13:17:31 pst
Date: Sun, 14 Feb 88 13:17:31 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802142117.AA00861@Gang-of-Four.Stanford.EDU>
To: JMC@sail, clt@sail
Subject: [boesch@vax.darpa.mil: Re: QLISP budget draft ]
Looks like JMC was right about Boesch's optimism... It seems to me
that most paring can be done on the lucid end. I cannot find anything
particularly extravagant on our end, except for the fact that csd-cf
is charging us exorbitant amounts for sail. Joe and I were discussing
this, and observed that if we were to to run sail entirely by
ourselves (including paying ME's salary) it would cost us less than
the $200k (this assumes that all other SAIL users would be given free
accts). I don't suppose anything can be done about this, but it is
food for thought... I have come up with a THREE month budget, which is
pared to the bone (pretty much). I'll send it out in a separate email.
Since boesch wants it "yesterday", I'll appreciate speedy commentary.
Igor
Return-Path: <boesch@vax.darpa.mil>
Posted-Date: Fri, 12 Feb 88 07:47:12 EST
To: Igor Rivin <rivin@gang-of-four.stanford.edu>
Subject: Re: QLISP budget draft
Cc: boesch@vax.darpa.mil
In-Reply-To: Your message of Tue, 09 Feb 88 02:19:34 -0800.
<8802091019.AA02306@Gang-of-Four.Stanford.EDU>
Date: Fri, 12 Feb 88 07:47:12 EST
From: boesch@vax.darpa.mil
I will need a short proposal for a $200K effort to last for about 3-4
months as the basis for the RADC contract that I plan to use to fund
you on the short term.
I will also need a complete proposal for the 18 Month effort, with
anticipated products resulting from the effort.
I have the Lucid proposal that they gave me. I need a proposal from
Stanford that includes Stanford's work as well as that of Lucid.
You may simply reference the Lucid Proposal for the Lucid portion of
the work.
Being naive(and new to darpa), I thought I would be able to get all of
the monies I asked for for this (and other efforts). It looks like
things will be tighter than I thought in my first note to you. Is
there anywhere that you can pare down the costs of the total effort?
Thanks.
PS: I need the short proposal IMMEDIATELY. Feel free to email it to
me. The longer proposal can wait a while but better get working on
that too 'cause we need to get going on that or we wil find ourselves
back in a crack again.
Thanks for your patience.
Brian Boesch
∂14-Feb-88 1329 rivin@Gang-of-Four.Stanford.EDU mini-budget
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:29:46 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00882; Sun, 14 Feb 88 13:29:38 pst
Date: Sun, 14 Feb 88 13:29:38 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802142129.AA00882@Gang-of-Four.Stanford.EDU>
To: jmc@sail, clt@sail
Subject: mini-budget
I have managed to come up with this lean way to stretch $200k over
three months. You will note that:
a) It lacks RWG and JSW
b) It has two student RAs as opposed to four.
c) It eliminates all hardware purchases.
d)it starts on March 1, so JMC and the students are paid at the acad.
year rate throughout.
e) It eliminates foreign travel, which may be a problem if RPG etc
want to go whereever they want to go before july.
One other note is that both student RAs are now named, since this
Kelly Roach guy (who was in my CA class and is pretty good) has
wants to hack some Computer Algebra. He seems to be interested
primarily in summer support at this juncture, but given the vagaries
of the funding situation, it probably can't hurt to put him in now...
Presumably, when I send this (or whatever) to Boesch, I will have to
point out that there is no way for $200k to last over as m many as
four months...
Qlisp budget
Proposal to DARPA
for
QLISP on Parallel Processors
Budget for 3 months beginning 1 March 1988
Personnel 18 Month Cost
Prof. John McCarthy (25% acad. yr. ) 6,142
Igor Rivin, Research Assoc. (100%) 12,036
Arkady Rabinov, Research Assoc. (100%) 13,869
Carolyn Talcott, Reseach Assoc. (50%) 6,807
Dan Pehoushek, Research Programmer (100%) 7,251
Alex Gorbis, Student Res. Assist. (50% acad. yr.) 2,910
Kelly Roach, Student Res. Assist. (50% acad. yr.) 2,910
Pat Simmons, Secretary (50%) 2,666
---------
Salary Total 50,881
Staff benefits (26.2% till 9/1/88, 13,331
27.1% thereafter)
Consultants (3 days @ $600) 1,800
Travel (2 East Coast trips/yr. @ $1200, 4,800
4 Western trips @ $600)
Computer maintenance 10,000
Computer time costs 30,000
Other direct costs 7,000
---------
Subtotal 117,812
Indirect Costs (73% of above) 86,003
---------
Total 203,815
∂14-Feb-88 1408 BRINK@Sushi.Stanford.EDU Missed your talk
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST
Date: Sun 14 Feb 88 14:02:50-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: Missed your talk
To: jmc@Sail.Stanford.EDU
Message-ID: <12374748334.12.BRINK@Sushi.Stanford.EDU>
... but not on purpose. Bad flu bug. Just now waking up, as it were. Sorry;
hoped to see you afterward.
I'm going ahead planning as though I were going to be at IBM for a while. Let
me know if anything appears on the horizon that might rea$onably involve me.
..Ed
-------
∂14-Feb-88 2026 helen@psych.Stanford.EDU Re: lunch?
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 20:26:13 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sun, 14 Feb 88 20:23:56 PST
Date: Sun, 14 Feb 88 20:23:56 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: lunch?
Sounds quite good. Lets say Saturday at noon. There is a very small
chance that I will be out of town. If this should happen, I'll let
you know as soon as I know. Otherwise, see you Saturday at noon in
front of Jordan/MJH!
-helen
∂15-Feb-88 0900 JMC
inference, reservations
∂15-Feb-88 0929 hearn%hilbert@rand-unix.ARPA Re: Software Subcommittee Reminder
Received: from rand-unix.rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:29:46 PST
Received: by rand-unix.rand.org; Mon, 15 Feb 88 09:23:10 PST
Received: by hilbert.arpa; Mon, 15 Feb 88 09:20:50 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8802151720.AA05571@hilbert.arpa>
To: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Cc: cweissman@dockmaster.arpa, hearn@rand-unix.ARPA, jmc@sail.stanford.edu,
mchenry@guvax.bitnet@rand-unix.ARPA, ouster@nutmeg.berkeley.edu,
blumenthal@a.isi.edu
Cc: hearn%hilbert@rand-unix.ARPA
Subject: Re: Software Subcommittee Reminder
In-Reply-To: Your message of Wed, 27 Jan 88 17:26:45 PST.
<8801280126.AA04143@nutmeg.Berkeley.EDU>
Date: Mon, 15 Feb 88 09:20:46 PST
My apologies for the delay in submitting my position statement on
software. I was out of the country for a couple of weeks, and have only
been back in the office for a few days. However, I now have the advantage
of being able to read other peoples' statements, so I don't have to repeat
anything that was said in those. I am however finding it hard to organize
my thoughts on this issue, as I have a lot of disparate points I'd like to
address. So this will be more-or-less stream of consciousness, I'm afraid.
My European trip took me to the International Center for Theoretical
Physics in Trieste, Italy, and CERN in Geneva. I used the opportunity to
ask questions about software controls to see what the reaction was. On
one question of access, I should mention that the people at CERN are
really annoyed at the position the US is taking on supercomputer access by
people from designated countries. They now have a Cray X-MP/48 which is
still under test but very close to being handed over. To satisfy the US
rules, there are card operated controls on all doors to the room in which
the Cray is housed, that keep track of all entrances and exits. I was
also told that the resolution of the access issue is that no person from a
designated country can have a password on the Cray. However, if they have
a scientific collaborator with an account, they will no doubt work
together on the Cray. Everyone I spoke to believes the whole thing is
idiotic.
I was also given a (hard) copy of some net correspondence on whether the
posting of a public domain DES to a bulletin board violated COCOM laws.
(I'm sending everyone a copy of this in an accompanying message --- please
read if you want more details on what I'm saying). Some interesting
points emerged. First, export administration regulations say that all
software is technical data. It also states that data that have been made
"generally available" to the public in any form is authorized for export
to all destinations. This suggests the following:
1) Any software that can be bought off the shelf (like Borland's stuff),
obtained for a modest fee from distribution centers (e.g., Argonne's
netlib, CERN's scientific library, Computer Physics Communications physics
library) or sources on bulletin boards like comp.sources.unix, can be
freely distributed anywhere in the world. Given the obvious ease of
reproducing software (pointed out in several statements) this is the only
really rational position to take.
2) As a result, I maintain that all *scientific* software that has been
distributed in source form outside the home institution cannot be
controlled.
3) If we adopted that position for most *application* software (a larger
class), there may be some economic benefit to the US, since purchasers
from conservatively run computer centers (i.e., all those in most
designated countries) may prefer to obtain individual copies from the
distribution source if the fees are seen as reasonable, rather than risk
being caught in copyright or license violation. My experience suggests
that the Eastern Europe and Soviet centers prefer to work this way.
However, this is *not* true of the Chinese, who, to quote a colleague in
Trieste, "copy everything they can get their hands on". But then of
course China isn't a signatory to the international copyright convention.
4) The *only* software that can be controlled is that, as described by
Clark Weissman, which is distributed in object-only form. However, if an
adversary wants to get a copy of the source, it is just too easy to
smuggle a copy out of the developing organization, unless that
organization has sufficient security to prevent this. I'm sure for
example that the Hungarian VAX copies are running VMS (though I forgot to
check on that when I was in the Soviet Union recently --- I'm sure Sy
knows the answer though).
5) I believe that the current COCOM regulations limit distribution of
expert systems or other classes of AI software. Systems like KEE or M-1
would be covered, since they are available for high fees, and hence not
"generally available" in the sense of the Commerce regulations. However,
given the existence of the Borland expert system shell, does it really
matter if such regulations were dropped? In other words, I consider it
reasonable that there are *no* governmental controls on *any* software,
leaving it to vendors to protect things as best they can.
Now to another topic. It's been pointed out that the US is paramount in
software at the present time. I think this has a lot to do with the
entrepreneurial nature of our society. Given that the start-up costs of
building software systems are small, a lot of people here are willing to
take the risk to develop software products. There's no incentive for such
activities in say the Soviet system or even the Japanese. As a result,
the only things we see from such countries are engineering improvements to
existing software (e.g., the IBM operating system enhancements), or
application packages for specific tasks (the Japanese efforts). On the
other hand, the Europeans seem to be better at some of the theoretical
stuff underlying software development, but can't seem to get their acts
together to make competitive software. Ok, there are exceptions (e.g.,
the French Ada compiler), but they're rare. An interesting exception
is the stuff coming out of Hungary --- the mixed economy is encouraging
people to develop things, and several interesting products have emerged
(e.g., a nice Pascal compiler). Again this may have something to do with
the national characteristics (good mathematicians --- entrepreneurial
spirit).
My conclusion on this point is that we shall maintain our software lead
for a long time to come, so the right Federal policy is to reduce controls
on software distribution to encourage exports. Federal efforts are better
put into making sure the copyright and licensing laws are satisfied so
that the export trade is maintained.
Well, that's a start. Let me know what the next steps are.
Tony
∂15-Feb-88 0931 hearn%hilbert@rand-unix.ARPA DES Software Distribution Correspondence
Received: from rand-unix.rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:31:14 PST
Received: by rand-unix.rand.org; Mon, 15 Feb 88 09:25:34 PST
Received: by hilbert.arpa; Mon, 15 Feb 88 09:23:06 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8802151723.AA05603@hilbert.arpa>
To: ouster%nutmeg.Berkeley.EDU@berkeley.edu (John Ousterhout)
Cc: cweissman@dockmaster.arpa, hearn@rand-unix.ARPA, jmc@sail.stanford.edu,
mchenry@guvax.bitnet@rand-unix.ARPA, ouster@nutmeg.berkeley.edu,
blumenthal@a.isi.edu
Cc: hearn%hilbert@rand-unix.ARPA
Subject: DES Software Distribution Correspondence
Date: Mon, 15 Feb 88 09:23:02 PST
Date: Thu, 28 Jan 88 03:07:00 EST
Reply-To: security@aim.rutgers.edu
Sender: Security mailing list <SECURITY@FINHUTC.BITNET>
Subject: distribution of sensitive software like DES
Comments: To: security-list@aim.rutgers.edu
----------------------------Original message----------------------------
A recent discussion of DES software distribution on one
of the Bitnet mailing lists came to a definitive resolution.
Since this seems to be security related, I thought the
readers of this list might find it interesting.
Selden Ball
system@crnlns.bitnet
--------------------------------------------
Date: Fri, 8 Jan 88 21:43:42 -0500
From: Rayan Zachariassen <rayan@ai.utoronto>
Subject: Re: DES
To: "Selden E. Ball, Jr." <SYSTEM@CRNLNS>
After you read the following article (referred to earlier by Dennis Ferguson),
hopefully the DES discussion will disappear from this list.
Date: Mon, 26 Oct 87 17:18:36 PST
From: John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
Subject: Export control does *NOT* apply to publicly available software.
To: info-futures@bu-cs.bu.edu
I researched this topic pretty thoroughly last year, by going down to the
local Federal Building and wading through the rulebooks in Commerce Dept.
library. What prompted me to do it was that I had a PD DES, that I had
posted to comp.sources.unix, which a Canadian reader claimed was in
violation of export laws.
Rich $alz took the info I got and talked with the NSA (US National
Security Agency) and some Boston-area cryptographers. The upshot was
that NSA never came up with anything that contradicted the rules I
found, and Rich posted not only the DES code, for worldwide distribution,
but also the "crypt breaker's workbench" that decrypts the ancient Unix
"crypt" command.
Now, the way things wag with NSA is that if you ask them "Can I do this?"
the answer is almost always "No". What you have to say is "Show me the rules
that say I can't do this. I have some that say I can." The courts have
regularly ruled that the government cannot enforce a policy which is not
written down and equally applied to everyone (it's called "secret law").
So if what *is* written down supports you, they are stuck with it. They
can't secretly make new laws and tell you later that you broke them.
Since everyone else on this topic is shooting off their mouth without
having done any research (now we have *two* Canadians who are falsely telling
us what the US export law is -- thanks guys!), I figured I'd better post
my full references to make it credible. Save this message; if I ever leave
the net somebody had better have a copy to shout down the clowns again.
From: gnu@hoptoad.uucp (John Gilmore)
Subject: There are basically no export controls on public domain information.
Date: 3 Oct 86 23:57:06 GMT
I got into a hassle last month for posting a DES program to mod.sources
because someone claimed that I was breaking the export control law.
I spent the afternoon down at the Federal Building and discovered that
export policy is in better shape than I thought. Basically, you can
export any technical data to any destination if it "has been made
generally available to the public in any form". This export is under
a "general license" which is available to everyone without any paperwork.
So, you should expect to see the DES posting again (it was canceled)
and to see Crypt Breaker's Workbench on mod.sources soon.
Here are the regs for all you policy hounds:
Export Administration Regulations, Part 370.2, Definitions.
"General License. A license established by the US Department
of Commerce for which no application is required and for which
no document is granted or issued. It is available for use by
all persons, except those listed in and prohibited by the
provisions of Supplement No. 1 to Part 388, and permits export
within the provisions thereof as prescribed in the Export
Administration Regulations. These general licenses are not
applicable to exports under the licensing jurisdiction of agencies
other than the Department of Commerce."
Part 379.1, Definitions.
"... All software is technical data."
Part 379.2, Licenses to Export.
"Except as provided in Part 370.3(a), an export of technical
data must be made under either a US Department of Commerce
general license or a validated export license. General
licenses GTDA and GTDR apply to specific types of exports of
technical data..."
Part 379.3, General license GTDA: Technical Data Available to all
Destinations.
"A General License designated GTDA is hereby established
authorizing the export to all destinations of technical data
described in 379.3(a), (b), or (c) below:
(a) Data Generally Available
Data that have been made generally available to the public in
any form, including--
(1) Data released orally or visually at open conferences,
lectures, trade shows, or other media open to the public; and
(2) Publications that may be purchased without restrictions
at a nominal cost, or obtained without costs, or are readily
available at libraries open to the public.
The term "nominal cost" as used in 379.3(a)(2) above, is intended
to reflect realistically only the cost of preparing and distributing
the publication and not the intrinsic value of the technical data.
If the cost is such as to prevent the technical data from being
generally available to the public, General License GTDA would not
be applicable.
(b) Scientific or Educational Data ...
(c) Patent Applications ..."
------ (end of first message)
John here, talking to info-futures again. Chris Lewis (the first
Canadian "expert") tried to pick the above to pieces, so I provided
more explanation by private mail, now revealed to the info-futures
readership for the first time ever!
Date: Sun, 12 Oct 86 16:57:06 PDT
From: gnu (John Gilmore)
Subject: Re: Export control revisited
Chris Lewis is still somewhat concerned about export control. I will
try to explain the things he mentioned in his message of 8 October.
>> "General License. A license established by the US Department
>> of Commerce for which no application is required and for which
>> no document is granted or issued. It is available for use by
>> all persons, except those listed in and prohibited by the
>> provisions of Supplement No. 1 to Part 388, and permits export
> ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> what is this section about?
It lists people who have abused the general license in circumstances
where it does not apply (eg shipping Vaxen to Russia). The idea is that
you are innocent until proven guilty with regards to general licenses.
I looked in the supplement and it was a 3-page list of names and cities.
I was not on it. :-)
>> within the provisions thereof as prescribed in the Export
>> Administration Regulations. These general licenses are not
>> applicable to exports under the licensing jurisdiction of agencies
>> other than the Department of Commerce."
I also got myself a copy of the regulations on cryptographic material
export, but I didn't include it in my posting since it did not apply.
It's listed under Part 399.1, supplement #1 (the Commodity Control
List), "ECCN 1527A". It mentions that computers when combined with
cryptographic software are covered under this ECCN, and says "Technical
Note: No technical data or software controlled under this ECCN may be
exported or reexported under General License GTDR." HOWEVER, we are
exporting under General License GTDA, not GTDR, and this is a valid
distinction. There is nothing in this ECCN section that precludes
shipping cryptographic technical data (e.g. software) under general
license GTDA. It also says, "Exporters requesting a VALIDATED LICENSE
from the Department of Commerce must provide a statement from the
Department of State, Office of Munitions Control, verifying that the
equipment intended for export is under the licensing jurisdiction of
the Department of Commerce." (emphasis mine) However, we are not
requesting a validated license, we are using the general license, so
this requirement does not apply either.
In summary, I believe that the provisions of ECCN 1527A do not apply to
public domain software, and we are OK. (I don't know of any other ECCN
sections that apply either.)
>> "A General License designated GTDA is hereby established
>> authorizing the export to all destinations of technical data ...
>>
>> (1) Data released orally or visually at open conferences,
>> lectures, trade shows, or other media open to the public; and
>>
>> (2) Publications that may be purchased without restrictions
>> at a nominal cost, or obtained without costs, or are readily
>> available at libraries open to the public.
> 1) Has *this* DES program been formally published before?
> 2) Can it legally be? Journals are supposed to be reviewed prior
> to publication by one of the security agencies. We're a loophole.
> 3) From another tack: can you make a DES program PD?
(1) You elided the relevent section of the general license definition.
"(a) Data Generally Available: Data the have been made generally
available to the public IN ANY FORM, including... (1) and (2)...".
(emphasis mine.) If something has been placed into the public domain
and its location advertised to the Usenet community, or placed into
a publicly accessible bulletin board, or posted to the Usenet, I claim
that it has been made generally available to the public. (1) and (2)
are not the only ways something can be made available to the public;
they are just examples.
(2) You can't be expected to know how things work in the U.S., being
Canadian, but there is NO requirement that "journals are supposed to be
reviewed prior to publication". We have a free press here. They tried
to impose something like this and it didn't work. There is a
"voluntary" system whereby authors can submit manuscripts to the NSA
for review, but you are not even bound by the result -- they can only
make suggestions. Mostly this is so they can recommend that you delete
certain phrases that might give away what they are working on, and you
are supposed to feel patriotic enough to go along. Presumably they
could also try to go to court to stop you from publishing, but I don't
think that has happened to any paper that has been voluntarily
submitted under this program. (They did go to court against the
magazine that published the "how to build an atom bomb" article.)
You may be confused between mandatory review of journals and the
Defense Department's right to review articles by people who they fund.
If you are doing government-sponsored research, they can write the
contract such that they get to OK any release of information derived
from the sponsored research. But if I invent something on my own,
without gov't money, I can publish it.
(3) Public Domain-ness is a state of ownership. Since you can
certainly own a DES program (e.g. AMD owns the copyright of the 8068
DES chip; ATT owns crypt(1)), you can also renounce its ownership and
place it into the public domain.
>You didn't include anything from 370.3 (or is that a typo?) either.
It was not a typo. I don't have a copy of it here, but I don't think
it applies to us. It's part of the "General Policy on Exports" section.
>If this program were to be published in a technical magazine (presumably
>safest in a real journal, not necessarily BYTE), then I'd feel safe
>because they've already had approval. BYTE published one or two DES programs
>ages ago, but this was before the NBS standard was formalized. Presumably
>you could publish *that* program (6502 assembler), but not anything written
>since then. I haven't seen a DES program since (though, I don't read all
>that many journals...)
This objection is covered above -- there is no required government
review of publications here, and no government approval is required to
publish.
>I realize perfectly well that a court challenge on this would probably
>find in our favor - as in, is DES in software really DES? But, I want
>to ensure that we stay well clear of the shadow (if not the substance)
>of the law.
Actually, this is not relevant. The export control regs don't mention
DES at all. They say "cryptographic equipment...designed to ensure
secrecy of communications...or of stored information...and "software"...
performing the functions of such cryptographic equipment", and then
make a few exemptions for things like simple scrambled voice, video, or
fax.
>I can't help remembering the export restrictions on crypt (which, I believe
>are still in effect *even tho* Enigma has been declassified for years),
>AT&T's security package, Motorola and Intel's encryption boards etc.
>I remember seeing discussions in trade journals 2-4 years ago about DES
>export restrictions, code-breaking discussions, other more recent encryption
>methods, but I can't remember where.
None of the above stuff is "technical data generally available to the
public", so it cannot be exported under the GTDA general license. Note
that journal articles like the AT&T Tech Journal one on breaking crypt
are generally available to the public, and they are being exported
without trouble. Ditto for _Cryptologia_. It *DOES* take an export
license to export non-public technical data, e.g. the Unix crypt
command (licensed software), encryption boards (hardware, not
technical data), etc.
I must say that I felt the same way you do about this -- I had a general
feeling that exporting this stuff was illegal, even though I thought it
should be legal -- until I spent the time to research it. My opinion of
the people who wrote US export law has gone up significantly. They
really believe that if the US "public" can get it, it is exportable.
FYI, here is the definitive story on how the "export restrictions on
crypt" came about, from Dennis Ritchie himself. As you can see, no
government agency ever said it could not be exported; AT&T and DEC
simply decided that applying for an export license was too much trouble.
I've also included a message from Gordon Moffett who says that Amdahl
is now exporting Unix with the crypt command without trouble.
From: dmr@research.UUCP
Subject: export controls
Date: 18 Sep 84 05:15:46 GMT
Posted: Mon Sep 17 22:15:46 1984
As has been said, there is indeed a special "International Edition"
of System V that differs from the ordinary system in that it
lacks the crypt command, the encrypting features of ed and vi, and the
encrypt entry of crypt (3). The crypt entry, which is used for
passwords, is there, as is the underlying DES algorithm.
Here's how it happened.
About a year ago, I got mail from Armando Stettner saying basically,
"Do you know of any problems with exporting crypt? Our lawyers
[at DEC] are worried about it." I replied that such worries were
utterly unfounded for a variety of sensible reasons.
Now, as it has turned out, DEC was very justified in worrying about
export controls in general; they have recently been fined (I think) $500,000
for the Vaxen that almost got sent to Russia. I conjecture that
the earliest stages of this or a similar incident were already in progress
and they were trying to be extra careful when they learned about crypt.
At any rate, the DEC lawyers communicated their fears to AT&T,
and the AT&T lawyers, equally cautious, sought government advice.
The problem, you see, is that cryptographic materials are under export
control. There is a thing called the Munitions Control Board that worries
not only about machine guns going to Libya, but also about the crypt
command going to England. In practice, the enforcement is done by the
Commerce department.
AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was
that they decided it would be simplest all around just not to export
the crypt command. The gov't would almost certainly have granted
the license, but (probably wisely) AT&T decided it wasn't worth
the hassle.
In technical terms, the situation is ludicrous. The encrypt subroutine
is distinguished mainly by the excruciating care I took to make it
an exact transcription of the algorithm published in the Federal Register,
and by its slowness. NBS, the caretaker of DES standardization,
is explicit that software implementations cannot be certified, so in that
sense encrypt is not "real" DES. The underlying subroutine is still
there, only the simple command that uses it is missing. So there is
actually nothing to protect, and even if there were, it's not protected.
Nevertheless, in the present situation we officially don't need
an export license, whereas with the crypt command we would.
In political terms, AT&T probably could have done better. Conservative
and careful, they called a big meeting at which no one could possibly
have put forward anything but official positions about encryption
programs. Private checking with well-placed people in the appropriate
agencies might well have done the job. But who knows?
Dennis Ritchie
-----
In article <3140@amdahl.UUCP> Gordon Moffett writes:
Our Corporate legal advisor says that the restrictions against
exporting encryption stuff has been lifted. We used to have two
UTS's: one with the crypt(3) stuff for domestic customers, and one
without export. We no longer distiguish between the two -- we now ship
everything to non-USA customers just as to the USA sites.
I've already gotten one letter about this, asking me for further
confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk
to *your* companies' legal advisors, or to the Federal Government
directly. Second, I am sure we would hear about it from the Federalees
if our Corporation were making a mistake ....
--
Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam
[Back to Chris's comments: -- gnu]
>The definitive answer would be to see whether the current listing of
>restricted items includes DES, and in what forms. I don't think excerpts
>from a different set of legislation is sufficient to answer this question.
>Further, there *may* be a difference between "legislation" and "regulation"
>here. DES restriction might *not* be enshrined in legislation, but come
>out of some other department's regulatory powers. The second paragraph
>I've quoted still leaves that whole question open.
I have spent the time researching it, and I think it's OK to export.
If you still think differently, please give details of the regulations
or laws involved. I'm not interested in "maybes"; I have an answer
that came straight from the rule books, and won't be swayed from it
by anything less definitive.
∂15-Feb-88 0930 DEK ooops
(I biked in to MJH this morning before I remembered our lunch date.
How about meeting here instead of at my house?)
∂15-Feb-88 1148 rivin@Gang-of-Four.Stanford.EDU budget
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 11:48:10 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03031; Mon, 15 Feb 88 11:48:06 pst
Date: Mon, 15 Feb 88 11:48:06 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802151948.AA03031@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: budget
I assume that it's OK, and I can send it off to Boesch...
Igor
∂15-Feb-88 1302 rivin@Gang-of-Four.Stanford.EDU short term proposal
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 13:02:50 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03261; Mon, 15 Feb 88 13:02:05 pst
Date: Mon, 15 Feb 88 13:02:05 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802152102.AA03261@Gang-of-Four.Stanford.EDU>
To: boesch@vax.darpa.mil
Subject: short term proposal
Cc: jmc@sail, clt@sail
Here is a short term budget you requested. You will note that it is
for three months only -- it actually took some doing to squeeze three
months out of $200k (all hardware upgrades/purchases had to be
postponed and likewise for new hires). In view of this I would think
that it is unrealistic to expect as many as four months at that
funding level. Also find enclosed a bulletized proposal/summary,
containing separate bullets for the short-term contract and for the
remainder of the eighteen month period. The work in the remainder of
the eighteen months presupposes the proposed level of funding, and
will have to be cut down somewhat in view of your last email, but in
the meantime I hope it will be of some use to you nonetheless.
In any event, many thanks for your efforts on our behalf, and do not
hesitate to let me know if you need more information.
Igor
Qlisp budget
Proposal to DARPA
for
QLISP on Parallel Processors
Budget for 3 months beginning 1 March 1988
Personnel 3 Month Cost
Prof. John McCarthy (25% acad. yr.) 6,142
Igor Rivin, Research Assoc. (100%) 12,036
Arkady Rabinov, Research Assoc. (100%) 13,869
Carolyn Talcott, Reseach Assoc. (50%) 6,807
Dan Pehoushek, Research Programmer (100%) 7,251
Alex Gorbis, Student Res. Assist. (50% acad. yr.) 2,910
Kelly Roach, Student Res. Assist. (50% acad. yr.) 2,910
Pat Simmons, Secretary (50%) 2,666
---------
Salary Total 50,881
Staff benefits (26.2% till 9/1/88, 13,331
27.1% thereafter)
Consultants (3 days @ $600) 1,800
Travel (2 East Coast trips/yr. @ $1200, 4,800
4 Western trips @ $600)
Computer maintenance 10,000
Computer time costs 30,000
Other direct costs 7,000
---------
Subtotal 117,812
Indirect Costs (73% of above) 86,003
---------
Total 203,815
QLISP Summary
The First Eighteen Months:
oo QLISP implementation on the Alliant FX/8
This has been proceeding at a good pace, after some intial delay
setting up the Stanford-Lucid computer link.
o Lucid Common Lisp has been implemented. (March 87)
o QLET T has been implemented. (July 87)
o QLAMBDA T has been implemented. (December 87)
o Several convenient locking primitives have been designed and
implemented. (December 87)
o Dynamic variables have been implemented using the deep binding
strategy. (January 88)
o Several task-scheduling algorithms have been implemented and tested.
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
oo Applications Development
QLISP programs have been showing speedups of greater than 3x on the
four processors we have. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
The Lisp programs implemented started from "toy" examples, such as
Fibonacci, then progressing to implementations of original parallel
algorithms for sorting, to implementing some of the Gabriel
benchmarks (Boyer, Tak), to polynomial arithmetic to fairly
sophisticated computer algebra problems (univariate polynomial
Greatest Common Divisor), as the Qlisp implementation has grown
more robust. Computer Algebra is considered to be an appropriate
testbed for Qlisp, since there are several well established
fundamental problems and time-tested (sequential) algorithms to
tackle these problems.
In the current Lucid implementation, it takes about .3 milliseconds
to spawn a process, so as long as the granularity of a problem is
considerably greater
than that, good speedups can reasonably be expected. The number of
active processes should be no more than around a thousand and certainly
no less than the number of processors in order for reasonable speedups to
be achievable. In many of the applications below, these conditions have
been met.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming.
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort.
(August 87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented. (December 1987)
The Next Eighteen Months (the dates below are targets for completion, work
is predicated on the proposed levels of funding)
oo QLISP implementation on the Alliant FX/8 (mini-contract for next
4-5 months)
o Non-local exits via CATCH and THROW will be implemented. (March 88)
o The implementation of deep binding will be improved.
o Bugs in the underlying Lisp caused by multiprocessing will be fixed.
(April 88)
o Some simple debugging tools will be implemented. (July 88)
o The 'EAGER forms of QLET and QLAMBDA will be implemented. (June 88)
o The EAGER forms of QLET and QLAMBDA constructs will be implemented.
(June 88)
oo Application Development (mini-contract)
o The present Computer Algebra effort will continue. Next on
our agenda are a parallel implemetation of Hensel's lemma and of
multivariate polynomial Greatest Common Divisor algorithms.
o A reference manual for Qlisp will be produced. (May 88)
oo QLISP implementation on the Alliant FX/8 (the remainder of the 18
months)
o Work will continue on task-scheduling strategies.
o The problem of resource management in a multi-processing
environment will be addressed. (September 88)
o Better performance-monitoring tools will be designed. (September
88)
o An effort will be made to establish a benchmark suite for
shared-memory multiprocessing Lisps in collaboration with other
groups working on such Lisps (MIT's Multilisp project, BBN's
Butterfly Lisp and other projects both in this country and Japan).
(January 89)
o A more usable program development environment will be designed.
(prototype system by March 89)
oo Applications Development (remainder of 18 months)
Experiments will be conducted with implementing medium-to-large
systems.
o A more extensive Computer Algebra implementation effort will be
underway, once the infra-structure is in place (Continuous through
duration of contract).
o Other application domains in symbolic processing will be investigated
(continuous)
o A Qlisp User's Guide for the benefit of the research community will be
produced. (first draft by January 89)
oo Ports to Other Hardware
The Alliant FX/8 is limited both in computing power (at most
eight processors) and in generality of code written for it (the
code is likely to not be easy to port to other multiprocessors).
These problems will be addressed.
o Hardware vendors other than Alliant are presently being
investigated as targets for Qlisp implementation -- having Qlisp
available on other machines will make it more widely available to
experimentation by DARPA research community.
o Porting to Encore under MACH will be evaluated. (by August 88)
o Distributed extensions under MACH will be evaluated. (by January 89)
o Multitasking will be evaluated under MACH, so that parallel programs
can be run on uniprocessors. (by January 89)
∂15-Feb-88 1314 yao.pa@Xerox.COM Re: Industrial Lectureship
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 13:14:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 12:48:57 PST
Date: Mon, 15 Feb 88 12:48:56 PST
From: yao.pa@Xerox.COM
Subject: Re: Industrial Lectureship
In-reply-to: "Your message of 10 Feb 88 16:28 PST"
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Cc: yao.pa@Xerox.COM
Message-ID: <880215-124857-1832@Xerox>
Dear John,
Thank you for your message. According to the Stanford Catalogue, Leo Guibas
teaches a Computational Geometry course (No. 368) in the Winter. Assuming it
will be given next year, I think my special topics course probably should not be
offered concurrently, and Spring may be the best time if your schedule permits.
I will send you a course description shortly.
Frances
∂15-Feb-88 1450 VAL CBCL
In the published version of the CBCL paper, the second of the following 2
sentences is missing:
CBCL should have an important property enunciated by Chomsky
in his {\it Reflections on Language} as a characteristic of human language.
(Linguists tell me that whether natural languages have it is controversial,
but whether they do or don't, CBCL shall have it).
Do we want to include it?
∂15-Feb-88 1556 Qlisp-mailer change to release-lock routine
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 15:55:57 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03873; Mon, 15 Feb 88 15:55:56 pst
Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 15:56:17 PST
Received: from bhopal.lucid.com by edsel id AA29694g; Mon, 15 Feb 88 14:23:48 PST
Received: by bhopal id AA16882g; Mon, 15 Feb 88 14:28:57 PST
Date: Mon, 15 Feb 88 14:28:57 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802152228.AA16882@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: change to release-lock routine
After talking with Joe the following changes to RELEASE-LOCK have been made:
When a lock is freed via RELEASE-LOCK a check is first made if the lock is
already free or if some other process is the current owner of the lock. If
either of these conditions is true then a continuable error occurs unless
RELEASE-LOCK had been called with the corresponding keyword parameter
:ok-if-not-locked or :ok-if-not-owner set to T.
This change is now in new-qlisp. RELEASE-LOCK now also returns the lock as
it's value.
A new version of new-qlisp should be available in a few days. It will have
the problem with bignums fixed along with several other slight modifications.
One change is that special print functions will be used to print lock and
process structures.
Ron
∂15-Feb-88 1654 GENESERETH@Score.Stanford.EDU tentative darpa schedule
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 16:54:07 PST
Date: Mon 15 Feb 88 16:48:54-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: tentative darpa schedule
To: nilsson@Score.Stanford.EDU, latombe@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, val@Sail.Stanford.EDU, ginsberg@Sushi.Stanford.EDU
cc: singh@Score.Stanford.EDU
Message-ID: <12375040711.13.GENESERETH@Score.Stanford.EDU>
Guys,
On the basis of a discussion among njn,jcl, and mrg, there is a
new tentative schedule for the schwartz visit. McCarthy slot is
only slightly affected by the changes (later than before). However,
there are other changes. Please comment so that I can finaluize this soon.
Note I have taken a couple of liberties with the schedule ``agreed upon''
by njn, jcl, and mrg, in order to give the presentation more structure,
as requested by njn.
mrg
Schedule for
DARPA AI Review
Overview of Afternoon (Nilsson) 1:00-1:10
Overview of Robotics (Latombe) 1:10-1:30
A. (Khatib) 1:30-1:50
B. (Binford) 1:50-2:10
Autonomous Construction Robots (Genesereth) 2:10-2:20
C. Motion Planning (Latombe) 2:20-2:40
Task-Level Reasoning
A. Engineering (Genesereth) 2:40-2:50
BREAK 2:50-3:00
B. Helios demonstration (Singh) 3:00-3:30
C. Logic, Reasoning, Control (Genesereth, etc.) 3:30-3:50
Agent Architecture (Genesereth) 3:50-4:00
A. Production System Architecture (Nilsson) 4:00-4:20
B. Communicating Agents (Nilsson) 4:20-4:40
Common Sense Knowledge (McCarthy) 4:40-5:30
Discussion 5:30-6:00
----------------------------------------------------------------
Total amounts of talking in minutes (without discussion):
Nilsson 50
Latombe 40
Khatib 20
Binford 20
Genesereth 50
Singh 30
McCarthy 50
---
260
-------
∂15-Feb-88 2304 enea!LISBET.LiU.SE!M-REINFRANK@uunet.UU.NET nmr-workshop
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 15 Feb 88 22:56:19 PST
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA02676; Tue, 16 Feb 88 01:56:28 EST
Received: by enea.se (5.57++/1.17)
id AA06636; Sat, 13 Feb 88 13:04:57 +0100 (MET)
Received: from LISBET (lisbet.liu.se) by majestix.liu.se; Sat, 13 Feb 88 12:39:49 +0100
Date: Sat 13 Feb 88 12:37:07
From: Michael Reinfrank <mre@ida.liu.se>
Subject: nmr-workshop
To: jmc@sail.stanford.edu, hayes.pa@xerox.com
Cc: m-reinfrank@lisbet.liu.se
Message-Id: <6PL53DS.K.M-REINFRANK@LISBET>
Dear Pat Hayes, dear John McCarthy:
we meanwhile have closed the submission list for our non-monotonic
reasoning workshop, and we have received 68 papers, out of which around
20 will be selected for presentation at the workshop.
I'd be glad if you would let me know about your plans concerning your
own contribution. You might remember that we'd appreciate your giving
a presentation, but that you're also welcome to attend without giving
a talk, and just contribute to the discussions.
I don't know whether it makes sense according to your present research, but
you might also wish to consider contributing a joint presentation.
Anyway, I would be fine if you could tell me about your plans by
early March, since the programme committee of the workshop will meet
during March 14/15. The meeting will be held in Standord, and I'll stay
there for a couple of days. So maybe there's an opportunity to meet
sometime during the middle of March.
Here's how you can reach me:
Before March 1st After March 1st
Michael Reinfrank Michael Reinfrank (my name sort of persists)
Dept. of Comp. Sc. ZT ZTI INF 22
Linkoeping Univ. SIEMENS AG
58183 Linkoeping Otto-Hahn-Ring 6
SWEDEN 8000 Muenchen 83
GERMANY
phone: **46-13-281937 **49-89-636-47587
-281480 -2414
fax: **46-13-142231 **49-89-636-48648
e-mail: mre@liuida.uucp reinfra@ztivax.uucp
Looking forward to seeing you in Munich, and maybe also in Stanford.
Regards,
Michael Reinfrank
-------
∂16-Feb-88 0041 Mailer Airline Deregulation [was re: Inc. letter for Boobists to consider]
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 00:41:39 PST
Date: Tue 16 Feb 88 00:36:43-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: Airline Deregulation [was re: Inc. letter for Boobists to consider]
To: JMC@Sail.Stanford.EDU
cc: su-etc@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 14 Feb 88 21:24:00-PST
Message-ID: <12375125874.15.SINGH@Sierra.Stanford.EDU>
Prof. McCarthy,
You ask:
``
Aha! Harinder, was airline deregulation a mistake?
''
As a newcomer to the West from a small desert village in India,
I'm not familiar enough with aviation to attempt a cogent response to
that deep question. 'Twould have been easier, by far, to comment on the
handling of recalcitrant she-camels in heat. ( As my part in promoting
glasnost and detente, I will spare Mr. Vardi an honorable mention here.)
Another lofty question does, however, come to mind:
Why are Boobists, in general, often seen taking _flying_
leaps across the chasm that separates the endorsement of free,
relatively un-regulated markets from that of predatory competitive
practices? Maybe this is also a consequence of deregulated air
travel - I dunno.
Ah jes hopes dey doan cut corners on de mintnence of dem
flyin' buses. Dat scare me good.
Inder Singh, Lt. Col.
3rd Rajputana Camel Corps
-------
∂16-Feb-88 0917 BJORK@Score.Stanford.EDU Link
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 09:17:40 PST
Date: Tue 16 Feb 88 09:12:29-PST
From: Steven Bjork <BJORK@Score.Stanford.EDU>
Subject: Link
To: jmc@Sail.Stanford.EDU
Message-ID: <12375219766.12.BJORK@Score.Stanford.EDU>
It seems to be working. Usually if the mux is out of sync, a light
flashes. This had me fooled a bit, 'till I pressed reset anyway,
and things started working. At least, stuff is going to channel four,
which is the printer if I remember correctly.
--Steve
-------
∂16-Feb-88 1012 CLT
don't forget to contact neil jones
∂16-Feb-88 1025 hayes.pa@Xerox.COM Munich
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:25:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 FEB 88 10:18:22 PST
Date: 16 Feb 88 10:17 PST
From: hayes.pa@Xerox.COM
Subject: Munich
To: jmc@sail.stanford.edu
cc: hayes.pa@Xerox.COM
Message-ID: <880216-101822-3363@Xerox>
DOES it make sense according to our present research? How could we find out?
How about getting together ( for lunch ? ) say some time next week? MWF are OK
with me.
Pat
∂16-Feb-88 1242 MPS LA Trip
Leave San Jose (American 2208) 8:30
Arrive LA International at 9:42
Leave LA Intl (American 2043) 12:30
Arrive San Jose at 1:40
∂16-Feb-88 1244 MPS Paris Trip
This is a non-stop flight on Air France.
Leave SFO 9:20 on the 20th
Arrive Paris 4:40 pm on the 21st.
9:20 is pm
I will get the the number of the flight when Mr. Hersch
calls me back
∂16-Feb-88 1303 RPG Paris
That was the flight that I was on, but to have DARPA pay I have to
take Pan Am. I need to find some gravy train. Foo.
The meeting on wednesday is the important one, I guess. Though the
total meeting only lasts through thursday afternoon.
-rpg-
∂16-Feb-88 1449 RPG Common Prototyping Language
To: nilsson@Score.Stanford.EDU, bscott@Score.Stanford.EDU,
JMC@SAIL.Stanford.EDU
Betty, some of this message may come as a surprise to you, but there
will be some action items at the end that you may have to help handle.
I have been talking to DARPA about the possibility of the Institute at
Stanford, and they are prepared to begin some funding aimed at it
as soon as Stanford can get the tasking request in. The funding is
for the project entitled ``Common Prototyping Language'' and is
being pushed at DARPA by Scherlis and Schwartz.
From my discussions with DARPA, it appears that they may be in a position
within some months to begin funding 1 - 3 software institutes, and if they
do, mine would be one of them. However, they want to start with CPL right
away. The initial task is to write a specification of CPL. CPL is a very high
level language that can be refined into ADA or Common Lisp. CPL will remind
people of specification languages, but it will be a practical language with
excellent debugging facilities. It will feature very high level constructs and
abstract data types, as well as an reasonable language for gaining efficiency
without having to use ADA or Lisp. The first part of the specification will be
a working document on the design goals.
Later funding, which must be anticipated by the tasking, is the implementation
of the language and an environment around it.
Initially I would like to budget 1 FTE through CSD, which would be broken up
between myself and two other people who will later join the Institute.
The initial part of the work can be accomplished by these people.
I suppose that the three of us would become part time research associates
unless you, Nils, can think of some other arrangement. DARPA is interested in
my becoming PI of this work in the long term but are willing to accept temporary
PI-ship early on.
We can accomplish the work while being housed at Lucid, using facilities that
the Qlisp project uses here.
The things that are needed are a description of the task, which I can supply,
an initial budget, which is 1 FTE, and enough flexibility in the description
of the task that it can be expanded later.
Do any of you see any problems with this?
In terms of the Institute itself, I and some of the people who will start
it are putting together a 5-10 page high-level proposal for the scope of
the Institute. I am in the process of tying off many of my loose-end tasks
around Lucid so that I can start on CPL in earnest on March 1. At that time,
or sooner, I will be able to devote a lot of time towards starting it up.
-rpg-
∂16-Feb-88 1528 nilsson@Tenaya.stanford.edu Common Prototyping Language
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88 15:28:52 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA12407; Tue, 16 Feb 88 15:28:53 PST
Date: Tue, 16 Feb 88 15:28:53 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802162328.AA12407@Tenaya.stanford.edu>
To: RPG@SAIL.stanford.edu
Cc: bscott@Score.stanford.edu, JMC@SAIL.stanford.edu
In-Reply-To: Dick Gabriel's message of 16 Feb 88 1449 PST <8802162249.AA12342@Tenaya.stanford.edu>
Subject: Common Prototyping Language
Sounds fine to me. May I assume that JMC will be temporary PI and will
work with Betty and you on the proposal? -Nils
∂16-Feb-88 1526 MPS Mileage
You have 118,224 hours with United. To use these miles, you
must contact the Mileage Plus office 7-10 working days (by phone)
before the trip. They then send you something authorizing United
to use this to your benefit when you make your reservation.
Unfortunately, it won't do you any good for your trip to Paris.
Also, if you write them it takes 4-6 weeks before you receive the
authorization. I asked them to send me an update of the number of
hours you have and also information on the program.
∂16-Feb-88 1532 MPS address
Have you got Neil Jones address for me yet?
Pat
∂16-Feb-88 1605 BJORK@Score.Stanford.EDU Re: terminal not working
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 16:05:17 PST
Date: Tue 16 Feb 88 15:58:00-PST
From: Steven Bjork <BJORK@Score.Stanford.EDU>
Subject: Re: terminal not working
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 16 Feb 88 15:55:00-PST
Message-ID: <12375293587.12.BJORK@Score.Stanford.EDU>
I see stuff flashing on the data line for the printer (channel 4).
Is anything printing?
I'll look at the terminal ends again just to be sure.
--Steve
-------
∂16-Feb-88 1613 RPG CPL
To: nilsson@TENAYA.STANFORD.EDU
CC: bscott@Score.Stanford.EDU, JMC@SAIL.Stanford.EDU
I hope JMC will agree to do that. Unfortunately JMC and I must travel to
Paris starting saturday, and so I will have to ask that Harlan Sexton, one
of the first three, take my place in working with Betty on the proposal.
Scherlis informs me that we need to get something to DARPA by next week so
that DARPA's March 1 internal deadlines can be met. I will be able to get
a good start on it this week, and I think I ought to stop by and chat with
Betty thursday at some point. Betty, are you available in the late morning
or early afternoon?
-rpg-
∂16-Feb-88 1636 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
THE YALE SHOOTING REVISITED
Matthew Ginsberg
Stanford University
Friday, February 19, 3:15pm
MJH 301
We suggest a new approach to temporal reasoning and the Yale shooting
problem based on the idea of a "neurotic extension". This idea uses
justification information to distinguish between competing extensions,
and appears to lead to an analysis of temporal projection that is free
of the formal difficulties encountered by other approaches.
∂16-Feb-88 1658 BJORK@Score.Stanford.EDU Link
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 16:58:00 PST
Date: Tue 16 Feb 88 16:29:08-PST
From: Steven Bjork <BJORK@Score.Stanford.EDU>
Subject: Link
To: jmc@Sail.Stanford.EDU
Message-ID: <12375299255.12.BJORK@Score.Stanford.EDU>
SAIL had shut off some of those ttys. I suspect there's still a
problem with the printer, and I'm kind of stuck on that one.
A couple of the other lines should be working now. Only three of
the four lines were connected at your end, if I remember. All four
ports are hooked up at SAIL's end, so it should be possible to move
the terminal cable from the dead line to the spare. All four lines
are 2400 baud.
--Steve
-------
∂16-Feb-88 2204 Qlisp-mailer meeting
To: qlisp@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
As John and Igor will both be out of town
there will be no Qlisp meeting tomorrow (17Feb).
∂17-Feb-88 0900 JMC
Bell 408 732-0400
∂17-Feb-88 0955 GENESERETH@Score.Stanford.EDU possible final schedule
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 09:54:59 PST
Date: Wed 17 Feb 88 09:49:40-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: possible final schedule
To: nilsson@Score.Stanford.EDU, latombe@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, val@Sail.Stanford.EDU, tob@Sail.Stanford.EDU,
ginsberg@Sushi.Stanford.EDU, singh@Score.Stanford.EDU,
de2smith@Score.Stanford.EDU
Message-ID: <12375488679.33.GENESERETH@Score.Stanford.EDU>
Folks,
Here is the latest draft of the schedule for Schwartz's visit TODAY.
Note that the presentations will take place at the ROBOTICS LAB and
will start at 1:00.
mrg
Schedule for
DARPA AI Review
Overview of Afternoon (Nilsson) 1:00-1:10
Overview of Robotics (Latombe) 1:10-1:30
A. Sensor-Based Manipulator Control (Khatib) 1:30-1:50
B. Vision and Geometric Reasoning (Binford) 1:50-2:10
Autonomous Construction Robots (Genesereth) 2:10-2:20
C. Motion Planning (Latombe) 2:20-2:40
Task-Level Reasoning
A. Engineering (Genesereth) 2:40-2:50
BREAK 2:50-3:00
B. Helios demonstration (Singh) 3:00-3:30
C. Logic, Reasoning, Control (Genesereth, etc.) 3:30-3:50
Defaults and Control of Inference (Ginsberg) 3:50-4:10
Agent Architecture (Genesereth) 4:10-4:20
A. Production System Architecture (Nilsson) 4:20-4:30
B. Communicating Agents (Nilsson) 4:30-4:40
Common Sense Knowledge (McCarthy) 4:40-5:30
Discussion 5:30-6:00
-------
∂17-Feb-88 0955 GENESERETH@Score.Stanford.EDU LUNCH EARLIER
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 09:55:52 PST
Date: Wed 17 Feb 88 09:50:34-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: LUNCH EARLIER
To: nilsson@Score.Stanford.EDU, latombe@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, val@Sail.Stanford.EDU, tob@Sail.Stanford.EDU,
ginsberg@Sushi.Stanford.EDU, singh@Score.Stanford.EDU,
de2smith@Score.Stanford.EDU
Message-ID: <12375488843.33.GENESERETH@Score.Stanford.EDU>
AND lunch will be served at 12:30!!!!
mrg
-------
∂17-Feb-88 1016 SHOHAM@Score.Stanford.EDU the schwartz visit
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 10:16:49 PST
Date: Wed 17 Feb 88 10:11:33-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: the schwartz visit
To: nilsson@Score.Stanford.EDU, jmc@Sail.Stanford.EDU,
genesereth@Score.Stanford.EDU, latombe@Coyote.Stanford.EDU
Message-ID: <12375492663.31.SHOHAM@Score.Stanford.EDU>
I've been unhappy with the way this has been handled. I did not mind
and still don't that I won't have the opportunity to dazzle him
with my brilliance. But I resent being left out of the process
to the point where I don't know the schedule the very day of the
visit, and that the schedule is being changed without my input.
I think it's reasonable that all AI faculty, junior ones too, be involved.
I'll be there and will try to contribute to the good impression
I'm sure we'll make. Btw, I think starting out in the robotics lab is a good
idea, if a bit balatant.
Yoav
-------
∂17-Feb-88 1124 helen@psych.Stanford.EDU Question/advice
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:24:41 PST
Received: by psych.Stanford.EDU (3.2/4.7); Wed, 17 Feb 88 11:22:07 PST
Date: Wed, 17 Feb 88 11:22:07 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Question/advice
Cc: helen@psych.Stanford.EDU
Hi there,
I was wondering if you would have maybe an hour or half hour sometime
today or tomorrow to talk about some work I've been doing. I'm giving
a talk on it Friday and I'm sort of stumped as to how to present a
certain aspect of it. I'd like to ask your advice. Given the "lateness
of the hour" I won't be the least bit perturbed if you can't find time,
but I just thought I'd ask anyway. Thanks!
-helen
∂17-Feb-88 1150 MPS phone calls
Bill Reynolds (ME 3-3840) called. Please call.
Kathy Davis (Deans Office 3-3872) called re:
Les termination. Please call.
Pat
∂17-Feb-88 1159 @ai.toronto.edu:hector@ephemeral.ai.toronto.edu Its out, by gar!!
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:57:56 PST
Received: from [192.5.58.34] by RELAY.CS.NET id aa16594; 17 Feb 88 14:28 EST
Received: from ephemeral.ai.toronto.edu by ai.toronto.edu via ETHER with SMTP id AA10834; Wed, 17 Feb 88 14:15:17 EST
Received: from localhost (stdin) by ephemeral.ai.toronto.edu with SMTP id 26961; Wed, 17 Feb 88 14:21:11 EST
To: james@CS.ROCHESTER.EDU, bobrow@XEROX.COM, stefik@XEROX.COM,
kabowen@LOGICLAB.CIS.SYR.EDU, rjb@allegra.att.com, ec@cs.brown.edu,
dekleer.pa@XEROX.COM, jon.doyle@C.CS.CMU.EDU, forbus@P.CS.UIUC.EDU,
hayes.pa@XEROX.COM, hewitt@XX.LCS.MIT.EDU, hinton@C.CS.CMU.EDU,
hobbs@WARBUCKS.AI.SRI.COM, israel@WARBUCKS.AI.SRI.COM,
jmc@SAIL.STANFORD.EDU, val@SAIL.STANFORD.EDU, bmoore@WARBUCKS.AI.SRI.COM,
nilsson@SCORE.STANFORD.EDU, pentland@WARBUCKS.AI.SRI.COM,
watdaisy!dlpoole@math.waterloo.edu, reiter@ai.toronto.edu,
stan@WARBUCKS.AI.SRI.COM, stan%humus.bitnet@cunyvm.cuny.edu,
alberta!lksc@ubc-vision, briansmith@XEROX.COM,
stickel@WARBUCKS.AI.SRI.COM, tyson@WARBUCKS.AI.SRI.COM,
waldinger@KL.SRI.COM, tw@CSLI.STANFORD.EDU, woods@HARVARD.HARVARD.EDU,
mcdermott-drew@YALE.ARPA
Subject: Its out, by gar!!
Date: Wed, 17 Feb 88 14:21:13 EST
From: Hector Levesque <hector@ai.toronto.edu>
Message-Id: <88Feb17.142111est.26961@ephemeral.ai.toronto.edu>
What do you know? I finally have a copy of the McDermott critique issue of
Computational Intelligence. But just one. They were supposed to send me 50,
of course, so I could send them out to you, and when I get them, I will.
Until then, it's Vol. 3, No. 3, August 1987 (Ha!). Read all about it!
Hector
∂17-Feb-88 1400 Qlisp-mailer new-qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 14:00:06 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08351; Wed, 17 Feb 88 14:00:00 pst
Received: by labrea.Stanford.EDU; Wed, 17 Feb 88 13:58:56 PST
Received: from kolyma.lucid.com by edsel id AA09182g; Wed, 17 Feb 88 13:43:46 PST
Received: by kolyma id AA11160g; Wed, 17 Feb 88 13:52:08 PST
Date: Wed, 17 Feb 88 13:52:08 PST
From: Carol Sexton <edsel!carol@labrea.Stanford.EDU>
Message-Id: <8802172152.AA11160@kolyma.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp
There is a new new-qlisp which has all known bugs fixed.
Carol
∂17-Feb-88 1620 RDZ@Score.Stanford.EDU Party details
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 16:20:09 PST
Date: Wed, 17 Feb 1988 16:06 PST
Message-ID: <RDZ.12375557315.BABYL@SCORE.STANFORD.EDU>
From: RDZ@Score.Stanford.EDU
To: jmc@Sail.Stanford.EDU, clt@Sail.Stanford.EDU, jdp@Sail.Stanford.EDU,
val@Sail.Stanford.EDU, air@Sail.Stanford.EDU, jjw@Sail.Stanford.EDU,
rdz@Score.Stanford.EDU, glb@Sail.Stanford.EDU, jk@Sail.Stanford.EDU,
rww@Sail.Stanford.EDU
Subject: Party details
The welcome-back dinner for John and Carolyn will take place at the
Grand China restaurant, this Friday (2/19) at 7:30. The location is
5100 El Camino Real, Los Altos; the restaurant's phone number is
964-6464. The dinner will cost approximately $15 per person.
Ramin
∂17-Feb-88 1751 helen@psych.Stanford.EDU Re: advice
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 17:51:50 PST
Received: by psych.Stanford.EDU (3.2/4.7); Wed, 17 Feb 88 17:49:19 PST
Date: Wed, 17 Feb 88 17:49:19 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: advice
Cc: helen@psych.Stanford.EDU
Tomorrow I have a lab meeting from 12:30 to 1:45 p.m. Can we go to
faculty club as late as 2 p.m.? Or maybe before that, at 11 a.m.,
would be good. Either is fine. Let me know!
And thanks,
-helen
∂17-Feb-88 2114 helen@psych.Stanford.EDU Re: alternate plan
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 21:14:49 PST
Received: by psych.Stanford.EDU (3.2/4.7); Wed, 17 Feb 88 21:12:17 PST
Date: Wed, 17 Feb 88 21:12:17 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: alternate plan
Ok, I'll come to your office at 11:30 a.m. See you then and there!
-helen
∂18-Feb-88 0816 nilsson@Tenaya.stanford.edu Schwartz visit
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Feb 88 08:16:39 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15404; Thu, 18 Feb 88 08:12:20 PST
Date: Thu, 18 Feb 88 08:12:20 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802181612.AA15404@Tenaya.stanford.edu>
To: feigenbaum@sumex, rindfleisch@sumex, engelmore@sumex, jmc@sail, val@sail,
genesereth@score, shoham@score, ginsberg@sushi, latombe@coyote,
khatib@coyote, binford@coyote, buchanan@sumex, appelt@ai.sri.com,
stan@ai.sri.com, bmoore@ai.sri.com, singh@score
Cc: gibbons@sierra, levinthal@sierra
Subject: Schwartz visit
Thanks to all who participated in the "Jack Schwartz looks at AI at
Stanford" day. I attended all of the talks and think I can
confidently say that we all gave it our best shot. (That is, if Jack
decides not to support certain things here it won't be because we
failed to explain to him what we are doing in a convincing manner.)
Jack asked some good questions, but he also asked many that indicate
that he needs to learn a lot more about the
foundations/attitudes/assumptions of our science before we'll be able
to convince him that what we are all doing is important. Bob Simpson
indicated to me that he thinks we are all making progress on the
needed sea change in Jack's thinking.
Bob said he would get back to us soon with his assessment of how the
day went. I'll pass that on when and if I receive it. In the meantime,
here's one element of very good news: Jack pulled me aside immediately
after Oussama's and J-C's presentations and said that he would
like to see proposals (within the next week) on their topics (force
control and motion planning, respectively)! Jack also indicated that
existing projects that have $ increments due will be getting them.
-Nils
∂18-Feb-88 0900 JMC
Hurd
∂18-Feb-88 0900 JMC
Bell 408 732-0400
∂18-Feb-88 1045 RICHARDSON@Score.Stanford.EDU Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 10:45:29 PST
Date: Thu 18 Feb 88 10:40:07-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Lunch
To: jmc@Sail.Stanford.EDU
Message-ID: <12375760008.20.RICHARDSON@Score.Stanford.EDU>
Regret to inform you that Nils will not be able to make lunch tomorrow
with you and Gordon Bell - scheduling would be too tight. Please call me
with your home phone# if you want him to call you at home as I didn't
get it when I talked to you. Thanks - Susan
-------
∂18-Feb-88 1130 GINSBERG@Sushi.Stanford.EDU informal lunches on Thursdays
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 11:30:09 PST
Date: Thu 18 Feb 88 11:21:38-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: informal lunches on Thursdays
To: mugs@Score.Stanford.EDU, principia@Score.Stanford.EDU,
jmc@Sail.Stanford.EDU, val@Sail.Stanford.EDU, shoham@Score.Stanford.EDU
Message-ID: <12375767566.19.GINSBERG@Sushi.Stanford.EDU>
The response to my initial suggestion seems to have been pretty
good, so these informal lunches (for the formalists among us)
will indeed occur. The first one will be on Thursday, February 25,
at noon in room 252 of Jacks. Vladimir has suggested that we dub
the meetings "Formfeed", and that seems pretty good to me -- so be
it.
See you next Thursday!
Matt
-------
∂18-Feb-88 1234 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 12:33:13 PST
Date: Thu 18 Feb 88 12:25:46-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12375779240.19.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
February 19: Dr. Luca Cardelli (DEC SRC),
"A Gentle Introduction to Intuitionistic Type Theory"
February 26: Dr. Joseph Y. Halpern (IBM San Jose),
"Knowledge and Common Knowledge in a Distributed Environment"
-------
∂18-Feb-88 1403 VAL correction
I believe a minor correction is needed in the 1986 circ'n paper. In formula
(38), move(x,l) must be l. With your permission, I'm changing it in the
version for Ablex.
∂18-Feb-88 1418 VAL book
In your IJCAI-77 paper you write:
(McCarthy 1977a) treats circumscription in more detail.
...
McCarthy, J. (1977a). Minimal Inference --- A New Way of Jumping
to Conclusions (to be published).
Do we want to leave it as it is, or drop it, or include a note in the bibliography
explaining that this became the 1980 circ'n paper?
∂18-Feb-88 1442 BSCOTT@Score.Stanford.EDU VTSS Honorarium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 14:42:27 PST
Date: Thu 18 Feb 88 14:37:09-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: VTSS Honorarium
To: JMC@Sail.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12375803159.42.BSCOTT@Score.Stanford.EDU>
John, VTSS is paying you $200 for a lecture you gave for them on January 25.
This honorarium should appear on your March 7 salary payment.
Betty
-------
∂18-Feb-88 1649 Qlisp-mailer Qlisp language issues
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 16:48:06 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02427; Thu, 18 Feb 88 16:48:00 pst
Received: by labrea.Stanford.EDU; Thu, 18 Feb 88 16:48:23 PST
Received: from bhopal.lucid.com by edsel id AA14626g; Thu, 18 Feb 88 16:23:50 PST
Received: by bhopal id AA05944g; Thu, 18 Feb 88 16:29:10 PST
Date: Thu, 18 Feb 88 16:29:10 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8802190029.AA05944@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Qlisp language issues
Please take a look at a proposal for how to treat CATCH and THROW in Qlisp.
It can be found:
on go4: /qlisp/catch-proposal
on SAIL: catch.txt[1,arg]
at Lucid: /u/arg/ql/catch-proposal
I await your comments.
On another issue, QLAMBDA is supposed to evaluate to completion one set of
arguments before starting to evaluate the next set of arguments. This is true
when a process has been associated with the QLAMBDA, but if the propositional
parameter was NIL then the QLAMBDA becomes an ordinary LAMBDA and no longer
has this property of integrity; if several processes simultaneously call the
QLAMBDA then they will all be evaluating it in parallel. If the integrity is
to be preserved then a (sleep?) lock needs to be associated with the QLAMBDA
so that only one process can be executing it at any point. Any objections to
this being incorporated into QLAMBDA? Possible drawbacks?
Ron
∂18-Feb-88 1836 VAL CS326
Nils asked me about the contents of CS326 and observed that it has much in
common with 323 (based on "Logical Foundations of AI"). He thinks that it
may be useful to "combine or reorganize" the courses, and asked me to
think about it. How do you like this idea? Maybe if we make 323 a
prerequisite for 326, then there will be no need to extend 326 to 2
quarters, as you once suggested.
∂18-Feb-88 1839 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
THE YALE SHOOTING REVISITED
Matthew Ginsberg
Stanford University
Friday, February 19, 3:15pm
MJH 301
We suggest a new approach to temporal reasoning and the Yale shooting
problem based on the idea of a "neurotic extension". This idea uses
justification information to distinguish between competing extensions,
and appears to lead to an analysis of temporal projection that is free
of the formal difficulties encountered by other approaches.
∂19-Feb-88 0700 JMC
pills
∂19-Feb-88 0749 helen@psych.Stanford.EDU
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 07:49:47 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 19 Feb 88 07:47:09 PST
Date: Fri, 19 Feb 88 07:47:09 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Thanks!
∂19-Feb-88 0910 Mailer Re: Air Line Ticket Problem
To: su-etc@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
I think that attempting to violate a tariff through a falsehood is
fraudulent, in which case it is illegal.
Arthur
∂19-Feb-88 0930 JMC
cash
∂19-Feb-88 0955 CLT qlisp
Do you have any objection to using Qlisp money
(possibly non-existent) to fund the initial stages
of Dicks proposed institute?
If Dick leaves Lucid it seems to me that we ought
to seriously consider removing Lucid from the Qlisp loop.
∂19-Feb-88 1029 rivin@Gang-of-Four.Stanford.EDU [boesch@vax.darpa.mil: Re: short term proposal ]
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 10:29:32 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05025; Fri, 19 Feb 88 10:29:22 pst
Date: Fri, 19 Feb 88 10:29:22 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802191829.AA05025@Gang-of-Four.Stanford.EDU>
To: jmc@sail, clt@sail
Subject: [boesch@vax.darpa.mil: Re: short term proposal ]
Thoughts?
Return-Path: <boesch@vax.darpa.mil>
Posted-Date: Fri, 19 Feb 88 10:21:01 EST
To: Igor Rivin <rivin@gang-of-four.stanford.edu>
Cc: boesch@vax.darpa.mil
Subject: Re: short term proposal
In-Reply-To: Your message of Mon, 15 Feb 88 13:02:05 -0800.
<8802152102.AA03261@Gang-of-Four.Stanford.EDU>
Date: Fri, 19 Feb 88 10:21:01 EST
From: boesch@vax.darpa.mil
Proposal.
OK I've extracted the following from the proposal you submitted to me.
I think that it correctly states the desired actions. And costs.
I think that you are a little heavy on travel. I decreased it to 1
east coast and 3 weatern trips. and decreased computer time by $500.
Thus holding the total to less than $200K which is kind of a magic
number to RADC. If we go over that it will likely take longer to get
approval.
Here is the extracted proposal for the "mini contract"
Call or email if you have any strong feelings about my changes.
Brian Boesch 202-694-5800.
Proposal to DARPA
for
QLISP on Parallel Processors
Budget for 3 months beginning 1 March 1988
Personnel 3 Month Cost
Prof. John McCarthy (25% acad. yr.) 6,142
Igor Rivin, Research Assoc. (100%) 12,036
Arkady Rabinov, Research Assoc. (100%) 13,869
Carolyn Talcott, Reseach Assoc. (50%) 6,807
Dan Pehoushek, Research Programmer (100%) 7,251
Alex Gorbis, Student Res. Assist. (50% acad. yr.) 2,910
Kelly Roach, Student Res. Assist. (50% acad. yr.) 2,910
Pat Simmons, Secretary (50%) 2,666
---------
Salary Total 50,881
Staff benefits (26.2%) 13,331
Consultants (3 days @ $600) 1,800
Travel (1 East Coast trips @ $1200, 3,000
3 Western trips @ $600)
Computer maintenance 10,000
Computer time costs 29,500
Other direct costs 7,000
---------
Subtotal 115,512
Indirect Costs (73% of above) 84,324
---------
Total 199,836
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
STATEMENT OF WORK FOR STANFORD
CONTINUED RESEARCH INTO
THE PERFORMANCE OF QLISP
BACKGROUND
The QLISP development and evaluation project at Stanford has thus far
produced a number of results:
o Lucid Common Lisp has been implemented. (March 87)
o QLET T has been implemented. (July 87)
o QLAMBDA T has been implemented. (December 87)
o Several convenient locking primitives have been designed and
implemented. (December 87)
o Dynamic variables have been implemented using the deep binding
strategy. (January 88)
o Several task-scheduling algorithms have been implemented and tested.
(October 87)
o A robust simulator for QLISP has been implemented in Common Lisp.
(August 87)
This simulator has been used for preliminary testing of
applications and task-scheduling algorithms and identification of
potential problem areas in the QLISP implementation.
A number of small applications have been written to evaluate the
performance of QLisp and have shown speedups of greater than 3x on the
four processors. Simulator experiments have shown close to
linear speedups on much larger numbers of processors as well.
The Lisp programs implemented started from "toy" examples, such as
Fibonacci, then progressing to implementations of original parallel
algorithms for sorting, to implementing some of the Gabriel
benchmarks (Boyer, Tak), to polynomial arithmetic to fairly
sophisticated computer algebra problems (univariate polynomial
Greatest Common Divisor), as the Qlisp implementation has grown
more robust. Computer Algebra is considered to be an appropriate
testbed for Qlisp, since there are several well established
fundamental problems and time-tested (sequential) algorithms to
tackle these problems.
In the current Lucid implementation, it takes about .3 milliseconds
to spawn a process, so as long as the granularity of a problem is
considerably greater
than that, good speedups can reasonably be expected. The number of
active processes should be no more than around a thousand and certainly
no less than the number of processors in order for reasonable speedups to
be achievable. In many of the applications below, these conditions have
been met.
Programming in QLISP does not, so far, appear too much more difficult
than programming in Common LISP, and ideas have been formed about
the development tools required for facilitating QLISP programming.
o OPS5 has been ported to Qlisp by A. Gupta (of the Center for
Integrated Systems) and H. Okuno (of the Knowledge Systems
Laboratory).
o Some of the Gabriel benchmarks have been implemented, with
encouraging performance. (December 87)
o Several parallel sorting algorithms have been designed and
implemented, also with good speedups over the serial sort.
(August 87)
o Several parallel algorithms for Computer Algebra (specifically
for polynomial and integer arithmetic) have been designed and
some of them have been implemented. (December 1987)
EFFORT TO BE ACCOMPLISHED UNDER THIS SOW
Stanford shall perform the following tasks during the period of
this contract.
o Continue the present Computer Algebra effort.
o Develop a parallel implemetation of Hensel's lemma and of
multivariate polynomial Greatest Common Divisor algorithms.
o Produce a reference manual for Qlisp.
These tasks represent a direct extension of existing work at Stanford
and Lucid.
∂19-Feb-88 1119 Qlisp-mailer QAND, QOR
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 11:17:52 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05147; Fri, 19 Feb 88 11:17:45 pst
Date: Fri, 19 Feb 88 11:17:45 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8802191917.AA05147@Gang-of-Four.Stanford.EDU>
To: QLISP@Gang-of-Four.Stanford.EDU
Subject: QAND, QOR
Paraphrasing from Ron's go4:/qlisp/catch-proposal:
"
(QAND prop (f1) (f2) ... (fn))
(QOR prop (f1) (f2) ... (fn))
If f[i] returns a future, then return that as the result of QAND/QOR.
(this may not be right)."
I agree it is not right.
I do not like treating undetermined futures as non-nil values in QAND & QOR.
If one of the QAND/QOR sub-processes returns a future, a "replacement" process should
be spawned which immediately touches that future. -dan
∂19-Feb-88 1206 VAL book
The reference at the end of the map coloring paper reads:
Pereira, Luis Moniz and Antonio Porto (1980). {\it Selective Backtracking
for Logic Programs}, Departamento de Informatica, Faculdade de Ciencias
e Tecnologia, Universidade Nova de Lisboa, 1899, Lisboa, Portugal.
I suspect that the number 1899 in the last line must be dropped. Am I right?
∂19-Feb-88 1219 Qlisp-mailer EAGER and FUTURE
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 12:19:06 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05276; Fri, 19 Feb 88 12:18:59 pst
Date: Fri, 19 Feb 88 12:18:59 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8802192018.AA05276@Gang-of-Four.Stanford.EDU>
To: Qlisp@Gang-of-Four.Stanford.EDU
Subject: EAGER and FUTURE
As one of the more experienced QLISP programmers, I feel I should
comment on a couple of the QLISP language features. They seem to
need some criticism.
Futures cause alot of overhead for certain basic functions. Functions
like CAR, CDR, +, and - must always touch their arguments. I don't
like to pay this overhead in my serial language constructs. I should
only have to pay some overhead when I use parallel language constructs.
Futures are useful in 'EAGER environments, but I have yet to find a
decently sized program that requires the use of EAGER or Futures to
speed it up. Neither Boyer or GCD really need futures or EAGER. Are
these constructs necessary? Are they PRIMITIVE?
On a slightly different topic, how different is Qlambda from a great
big Lock mechanism? To tell the truth, I don't use QLAMBDAs either.
I use locks. They are direct, and easy to understand, and are alot
cheaper to use. I think that, behaviorally, Qlambda and With-lock are
closely related.
If you have a good example of a program that really needs EAGER or
FUTURE, I'd like to see it. I think everyone would. We should post
such programs and try to rewrite them without EAGER or FUTURE.
The parallel construct I use the most is #!, which is a macro for
PCALL. I also use locks for synchronization. With these two
"primitives", I can build my own parallelism constructs. As a common
lisp community member, I support the idea that the closer to
common-lisp, the better. Therefore, the fewer parallelism PRIMITIVES,
the better, as long as they are "sufficiently" powerful primitives.
QCATCH and QTHROW are certainly necessities, but Futures make them
potentially very messy.
-Dan
∂19-Feb-88 1500 Qlisp-mailer QAND, QOR
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 15:00:08 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05695; Fri, 19 Feb 88 14:59:55 pst
Received: by labrea.Stanford.EDU; Fri, 19 Feb 88 15:00:17 PST
Received: from bhopal.lucid.com by edsel id AA18622g; Fri, 19 Feb 88 12:29:50 PST
Received: by bhopal id AA07534g; Fri, 19 Feb 88 12:35:11 PST
Date: Fri, 19 Feb 88 12:35:11 PST
From: Jim McDonald <edsel!jlm@labrea.Stanford.EDU>
Message-Id: <8802192035.AA07534@bhopal.lucid.com>
To: pehoushe@gang-of-four.stanford.edu
Cc: QLISP@gang-of-four.stanford.edu
In-Reply-To: Dan Pehoushek's message of Fri, 19 Feb 88 11:17:45 pst <8802191917.AA05147@Gang-of-Four.Stanford.EDU>
Subject: QAND, QOR
There is another alternative, but it might be too complicated:
If f[i] returns a future, then return that as the result of QAND/QOR,
suspending f[j] for j neq i, and associating the future with the
suspended processes. When the future is finally about to be
resolved, if its value would be non-NIL/NIL and there are suspended
processes associated with it, resume all the suspended processes and
arrange for the future to await the new value from the QAND/QOR.
In essence, what this lets you do is have a process claim priority
on returning a value by quickly returning a future. For example,
for some kinds of verifications/searches there might be heuristics
that indicate success is unlikey/probable, but not certain yet.
This mechanism could be used to suspend competitors from (probably)
wasting resources, especially if the process returning the future
was convinced it was the critical path and was going to need
significant resources to finish.
A more general priority mechanism might obviate this, but it seemed
worth mentioning.
jlm (Jim McDonald eavesdropping)
∂19-Feb-88 1605 MPS
I left at four to take care of your photos. Have a great
trip in France. This should be the start of some good Paris
weather. Is there anything special you want me to do while
your away? Also, when will you be returning. Bon Voyage
Pat
∂19-Feb-88 1607 CLT [boesch@vax.darpa.mil: Re: short term proposal ]
To: rivin@GANG-OF-FOUR.STANFORD.EDU
CC: JMC@SAIL.Stanford.EDU
looks reasonable to me
∂20-Feb-88 0905 REGES@Score.Stanford.EDU CS101
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 88 09:05:40 PST
Date: Sat 20 Feb 88 09:00:25-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: CS101
To: jmc@Sail.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12376266144.41.REGES@Score.Stanford.EDU>
John,
What do you think about the viability of CS101? I think the primary
audience for the course has evaporated because CS105A and CS75 are now the
courses that satisfy the humanities students' area 8 requirement. Would you
be opposed to deleting it from the catalogue, or did you want to teach it
again?
-------
∂20-Feb-88 1026 REGES@Score.Stanford.EDU re: CS101
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 88 10:26:12 PST
Date: Sat 20 Feb 88 10:20:54-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: re: CS101
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sat 20 Feb 88 10:19:00-PST
Office: CS-TAC 22, 723-9798
Message-ID: <12376280798.41.REGES@Score.Stanford.EDU>
Okay, I'll do that. I'll list it as every other year to be taught by you
in '89-90. Do you want to change the course description? Below is a copy
of what I would print if you didn't want a change. Feel free to send back
an edited version for publication.
101. Computers: Their Nature, Use, and Impact--Intended to
introduce students from all departments to the computer revolution.
Designed for nonspecialists to survey a variety of concepts and issues
relating to computers. Topics include basic concepts and vocabulary
of computers and information processing; current applications of
computers in education, business, music, art, medicine, science,
entertainment, communication, consumer products, manufacturing,
defense, transportation, law, law enforcement, and government; future
trends in the economics of computing, technological advances,
artificial intelligence; impact of computers on issues of privacy,
employment, leisure, obsolescence, political and economic power, and
man's image of himself. Programming is not taught in this course.
Alternatives: 105A, 106A. (DR:8 Student must also have
completed CS 106 as taught before 9/1/85). No prerequisite.
3 units, Win (McCarthy)
alternate years, given 1989-90
-------
∂20-Feb-88 1034 Qlisp-mailer Conference announcement
To: qlisp@SAIL.Stanford.EDU
From: Joe Weening <JSW@SAIL.Stanford.EDU>
Here's an announcement I saw on USENET:
CALL FOR PAPERS AND REFEREES
HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES - 22
LANGUAGES FOR PARALLEL PROCESSING
KAILUA-KONA, HAWAII - JANUARY 3-6, 1989
The Software Track of HICSS-22 will contain a special set of
papers focusing on a broad selection of topics in the area
of Languages for Parallel Processing. One of the major
problems in parallel processing is the problem of expressing
an algorithm in parallel form. There are two broad ap-
proaches being proposed by various researchers: Implicit
Control and Explicit Control. These two approaches have im-
pacted the design of programming languages and tools.
Implicit Control languages are usually designed to hide the
parallel processing from the programmer, e.g. functional and
logic programming languages, vectorizing FORTRAN compilers,
etc. This poses a major problem for compiler writers because
of the difficulty of automatic parallel detection and opti-
mization.
Explicit Control languages usually extend an existing lan-
guage, or are designed as parallel processing languages,
e.g. OCCAM. A major difficulty here is in the design of the
language -- how can it be general enough to encompass all
forms of parallelism, and how can it avoid machine dependen-
cies? Can the programmer extend his application from a few
processors to a large number without altering his applica-
tion significantly. In this session, we want to explore the
many ways of designing and implementing languages for paral-
lel processing.
Papers are invited that may be theoretical, conceptual, tu-
torial or descriptive in nature. Those papers selected for
presentation will appear in the Conference Proceedings
which is published by the Computer Society of the IEEE.
HICSS-22 is sponsored by the University of Hawaii in cooper-
ation with the ACM, the Computer Society, and the Pacific
Research Institute for Information Systems and Management
(PRIISM). Submissions are solicited in:
o Restructuring translators
o Parallel optimizing compilers
o Design of new languages for parallel programming
o Visual and other paradigms for parallel programming
o Debugging applications in parallel languages
o Performance studies for parallel languages
o Performance tuning in parallel languages
o Special-purpose languages for systolic, distrib-
uted, or novel architectures
o Practical experiences with language constructs,
compilers, etc.
INSTRUCTIONS FOR SUBMITTING PAPERS
Manuscripts should be 22-26 typewritten, double-spaced pages
in length. Do not send submissions that are significantly
shorter or longer than this. Papers must not have been
previously presented or published, nor currently submitted
for journal publication. Each manuscript will be put
through a rigorous refereeing process. Manuscripts paper
should have a title page that includes the title of the pa-
per, full name of its author(s), affiliation(s), complete
physical and electronic address(es), telephone number(s)
and a 300-word abstract of the paper.
DEADLINES
o A 300-word abstract is due by March 30, 1988
o Feedback to author concerning abstract by April 15,
1988
o Six copies of the manuscript are due by June 6,
1988.
o Notification of accepted papers by September 1,
1988.
o Accepted manuscripts, camera-ready, are due by Oc-
tober 3, 1988.
SEND SUBMISSIONS AND QUESTIONS TO EITHER
Dr. Shreekant Thakkar Prof. Ted Lewis
Sequent Computer Corp. Computer Science Department
15450 SW Koll Parkway Oregon State University
Beaverton, OR 97006 Corvallis, OR 97331
(503) 627-9822 (503) 754-3273
e-mail: ticky@sequent e-mail: lewis@mist.cs.orst.edu
∂20-Feb-88 1120 helen@psych.Stanford.EDU Running a little late
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 88 11:20:15 PST
Received: by psych.Stanford.EDU (3.2/4.7); Sat, 20 Feb 88 11:17:29 PST
Date: Sat, 20 Feb 88 11:17:29 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Running a little late
Could we make our meeting for 12:15 or 12:30? I seem to be running
late...
-helen
∂21-Feb-88 1021 nilsson@Tenaya.stanford.edu Gordon Bell
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Feb 88 10:21:35 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA17493; Sun, 21 Feb 88 10:21:28 PST
Date: Sun, 21 Feb 88 10:21:28 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802211821.AA17493@Tenaya.stanford.edu>
To: JMC@SAIL.stanford.edu
In-Reply-To: John McCarthy's message of 20 Feb 88 1856 PST <8802210257.AA17145@Tenaya.stanford.edu>
Subject: Gordon Bell
I'm already tied up for lunch Friday (2/26). The earliest next
opening is Friday, 3/4, but I'm too busy right now to make the
arrangements and am temporarily without a secy.
∂21-Feb-88 1400 scherlis@vax.darpa.mil FINANCIAL AND TECHNICAL REPORTS
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 21 Feb 88 13:59:56 PST
Received: from sun45.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA04777; Sun, 21 Feb 88 16:57:00 EST
Posted-Date: Sun 21 Feb 88 16:51:51-EST
Received: by sun45.darpa.mil (5.54/5.51)
id AA23906; Sun, 21 Feb 88 16:51:53 EST
Date: Sun 21 Feb 88 16:51:51-EST
From: William L. Scherlis <SCHERLIS@vax.darpa.mil>
Subject: FINANCIAL AND TECHNICAL REPORTS
To: SW-PI@vax.darpa.mil
Message-Id: <572478711.0.SCHERLIS@VAX.DARPA.MIL>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
To all DARPA/ISTO Software PIs:
QUARTERLY TECHNICAL AND FINANCIAL REPORTS
1. We are finding that the information we maintain concerning
DARPA/ISTO supported efforts needs to be kept more current. As was
discussed during the PI meeting, DARPA is requesting contractors to
submit information to us on a periodic basis. In the Computer Systems
section of the office (including architectures, networks, software
technology, and distributed systems), a policy is being established to
ask contractors to submit quarterly reports. Reports are of a very
straightforward nature, and submission by netmail is requested.
Please send simple text files with a minimum of formatting.
2. Reports are to be submitted quarterly, within one week of the end
of the quarter. The next quarter ends on March 31.
3. Please send AS SOON AS POSSIBLE a financial report for the quarter
ending Dec 31, 1987. In this special report only financial and
administrative information is required. (See below for details.)
4. Reports should be submitted directly by netmail to the following
addresses:
Fenton@vax.darpa.mil Donna Fenton (202)694-5800
Scherlis@vax.darpa.mil Bill Scherlis (202)694-5800
If no acknowledgement is received from us within two days of sending,
please enquire with us to ensure recept.
5. Project Mailboxes. We will be sending various official
correspondence to you via netmail if at all possible. Please ensure
that we have on file a netmail mailbox that is regularly checked. I
suggest that each project create a new virtual project mailbox that
will forward to PIs and other responsible people. This will be useful
not only to DARPA, but to groups in the community that are seeking
project information and interaction.
5.1. I've tried to send this message to an appropriate person at each
software site/project. There may be some redundancy in coverage, so
check with your project colleagues (since they might also be receiving
this msg). If you receive multiple copies, it is probably due to the
fact that you are responsible for multiple projects. We try to
maintain a mailing list for all Software Technology PIs and selected
others.
6. Quarterly reports include both technical and financial information.
7. Technical information. A few paragraphs (i.e., LESS than a page)
is sufficient. Reports should be brief and to the point, addressing
the following:
a. Recent accomplishments and major events.
b. Immediate technical objectives and challenges.
c. New opportunities.
d. Major personnel changes.
e. Major recent publications. (Send us copies once in a while.)
Typically, the DARPA agent organization associated with your contract
(ONR, SPAWAR, RADC, NSF, DSSW, etc.) is already requiring this
information. The point is to provide a simple mechanism for you to
keep us informed of major events. A report of "no major events" is
acceptable once in a while. Please send us papers, but be selective.
8. Technical material from quarterly reports can be recycled for use in the
Annual Report due at the end of the summer.
9. Financial information. The following financial information should
be included separately. Dollar amounts can be in $K.
a. Arpa Order number, agent, and contract number.
b. Basic contract (if a task: task AND contract) dollar amount.
c. Dollar amounts and purposes of options, if any.
d. Start and end dates for task/contract. Mention no-cost extensions.
e. Total spending authority received to date. (Note the date.)
f. Total spent to date. (The information you provide will likely be
current only as of your internal reporting periods, so please
note for us the date to which it applies. Otherwise we will
use the current date and conclude that you are spending more
slowly than you really are.)
g. Monthly expenditure rate.
h. Any major non-salary expenses planned within this increment
of funds (and other deviations expected from item g).
i. Date next increment of funds is needed.
10. Annual Report. The dreaded annual report is TWO pages long
(perhaps THREE if you've had an unusual year), and includes:
[1] accomplishments of last fiscal year.
[2] objectives for next fiscal year.
[3] components produced by you.
[4] components produced by others consumed by you.
[5] some supporting prose explaining why the research is of value
and should be continued.
It is due in July, and it will be solicited in June.
11. SUMMARY. Here is what needs to be done NOW:
a. Submit a FINANCIAL report that is as current as possible,
including expenditure data (9.e and 9.f above).
URGENT: This should be done by Thursday, if at all possible.
NO technical information need be provided for this special
report.
b. Establish a project netmail mailbox and let us know what it is.
(We might also use US mail once in a while, but we generally
favor the net.)
c. Prepare for the end-March quarterly. (It should be about half the
size of this message.)
d. Keep quarterly reports on file to help with preparation of annual
report in the summer.
12. Respond separately for every Darpa project you manage, even if
they are supported through the same contract vehicle. (If this is
unclear, please call me for clarification.) We are trying to keep
reporting requirements to a minimum. Your assistance in providing
this necessary information is appreciated.
Thanks,
Bill Scherlis
-------
∂21-Feb-88 1618 VAL Plekhanov
He died in May of 1918.
∂22-Feb-88 0937 SLOAN@Score.Stanford.EDU Pat Simmons
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 09:36:59 PST
Date: Mon 22 Feb 88 09:31:32-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Pat Simmons
To: McCarthy@Sail.Stanford.EDU
Message-ID: <12376796099.16.SLOAN@Score.Stanford.EDU>
Pat will not be in today.
--Yvette
-------
∂22-Feb-88 0950 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Draft software report
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 09:49:51 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA12322; Mon, 22 Feb 88 09:42:11 PST
Date: Mon, 22 Feb 88 09:42:11 PST
From: ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU (John Ousterhout)
Message-Id: <8802221742.AA12322@nutmeg.Berkeley.EDU>
To: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.arpa,
jmc@sail.stanford.edu, mchenry@guvax.BITNET
Subject: Draft software report
Cc: ouster@nutmeg.Berkeley.EDU
This message contains my first attempt at a draft of the software
subcommittee report. I've tried to merge together all (or most) of
the information from your position statements. Please read it over
and send me your comments. I'm particularly interested in knowing
if you agree or disagree with the various statements in the report.
Where I disagreed with things you sent me, I stated things like "the
committee was divided on ..." and I'll do the same in places where
you disagree with what I wrote. I'm also interested in any other
suggestions you may have. Where you'd like to see non-trivial changes,
please send me text that I can work from, rather than just general
ideas.
I need to get all of your comments, additions, and corrections by
one week from today, Monday, February 29. That will leave me a few
days to incorporate your changes and get the draft to Washington.
-John-
Draft Report of the Software Subcommittee
NAS Committee to Study International Developments
in Computer Science and Technology
John Ousterhout
Tony Hearn
John McCarthy
Bill McHenry
Clark Weissman
1. Introduction and Overview
This document contains the initial findings of the
software subcommittee. It derives from a collection of
position statements submitted by the members of the subcom-
mittee. The body of the report consists of five sections.
The first section discusses the basic technology trends in
software as we see them, particularly the revolutionary
changes in the industry that have occurred because of the
arrival of a commodity market for software. The second sec-
tion describes four areas in which major breakthroughs seem
possibile: concurrent programming, formal techniques, non-
procedural languages, and encryption techniques. The third
section gives our impression of the major national players:
the U.S. appears to be clearly dominant at this time, but
many other countries are focussing increasingly on the
software market. The fourth section discusses the software
situation on Russia; our opinion is that the Soviets are
far behind the rest of the world and may have difficulties
in catching up soon. The last section discusses the issue
of protectability: our conclusion is that it is nearly
impossible to prevent the spread of software and that it may
be counter-productive to try.
2. Basic Technology and Market Trends
Our first task as a subcommittee was to survey the
state of the art in computer software and identify trends in
recent developments. The software industry has been revolu-
tionized by the arrival of personal computers and the accom-
panying explosion of software markets. This has changed the
nature of software development from monolithic systems
developed by large computer companies to small interoperat-
ing software components developed by small specialty firms,
encouraged the development of standards, resulted in vastly
better development tools, and created a greater focus on
networking and communications.
February 22, 1988
- 2 -
This section also discusses briefly an unrelated topic,
namely the development of international software.
2.1. Commodity Market
The most significant recent development in computer
software has been the commoditization of the market caused
by the arrival of IBM and Apple personal computers and their
clones. Fifteen years ago there were essentially no com-
panies whose primary business was to develop commodity
software packages. Software was developed almost
exclusively in large organizations: large computer companies
developed software systems that they shipped in packages
with their hardware, and other large organizations (banks,
insurance companies, airlines, etc.) developed large appli-
cation packages for their own internal use. Software tended
to be shipped only in small quantities and was almost always
bundled with hardware. In many cases software was given
away or sold extremely cheaply: it served chiefly as an
inducement to buy the hardware on which it ran.
Today the situation has changed in two major ways.
First, the widespread use of personal computers has made it
possible for software packages to be distributed in enormous
quantities. It isn't uncommon for a popular software pack-
age today to have a million copies shipped, where only a few
years ago a thousand copies would have been considered
extraordinary. Second, there are now hundreds of smaller
companies developing, marketing, and profiting from
software. Most of them do not do any hardware development,
so they are dependent entirely on software for revenues. A
few years ago many people thought that it was not possible
to create a large profitable software company; today, com-
panies like Microsoft, Lotus, and Ashton-Tate show this
theory to be false. Even large computer manufacturers like
IBM and Hewlett-Packard have been restructuring their pric-
ing so that software can become a revenue source by itself
instead of a loss-leader to bolster hardware sales. As much
as 30% of IBM's revenue now comes from software (can anyone
verify this?).
2.2. Standard Interfaces
The commoditization of the software market has been
accompanied by the emergence of standard interfaces at many
levels. Fifteen years ago there was very little agreement
among vendors about anything: each computer manufacturer had
its own self-contained software systems with proprietary
interfaces and no compatibility with any other manufacturer.
Today there are dozens of widely-accepted standards covering
such things as instruction sets (such as the Intel 8086 and
Motorola 68000), file formats, graphics libraries (such as
Macintosh QuickDraw and the X Window System), operating sys-
tem interfaces (such as PC-DOS, Unix, and OS/2), page
February 22, 1988
- 3 -
formatting languages (Postscript), and network protocols
(such as Ethernet, IP/TCP, and AppleTalk).
The motivation for adopting standard interfaces is that
the allow different companies to produce interoperable
hardware and software components. It no longer seems to be
possible for any one organization to produce all of the
software for a particular machine or environment. There
have been several major disappointments (such as Xerox's
Star and Apple's Lisa) where companies tried this approach.
The companies intended to produce virtually all of the
software for the systems in-house and intentionally made the
internal interfaces inaccessible or obscure. The result is
that very little software was developed for the machines and
the products were not successful. Most recent systems have
tended to be based on and to provide standard interfaces, so
that other manufacturers can develop additional software to
enhance the value of the system. The openness of the IBM PC
hardware and software, and the fact that those interfaces
became standards, are key reasons for the success of the PC.
2.3. Software Components
An overall effect of the trend towards commoditization
and standardization has been the development of a ``software
components'' business. Fifteen years ago software was typi-
cally distributed in large, monolothic, ``do-everything''
systems. Today software is more often marketed in small
packages. Spreadsheets, word processors, page layout pro-
grams, compilers, network communication, and many other
packages are all sold individually by different vendors.
The large volume of potential shipments means that even a
niche product can potentially generate large revenues. By
designing to existing standards, the new product can be used
in existing systems with many other existing software pack-
ages, so the new product's designers need not redevelop an
entirely new software environment. The result is that small
organizations can turn new ideas into exciting niche pro-
ducts very quickly.
2.4. Development Tools
Tools for software development have been one of the
major beneficiaries of the software components business. It
is now possible to buy a modern language development system
with editor, compiler, linker, loader, symbolic debugger,
and run-time library for a hundred dollars. New development
tools are being produced at a dizzying pace. The result is
that software technology is fueling itself: new tools shor-
ten the development cycle, which results in more application
packages, including better tools which shorten the develop-
ment cycle even more, and so on.
February 22, 1988
- 4 -
2.5. Distributed Systems
Another recent trend in software technology is towards
distributed systems. The arrival of personal computers and
workstations made networking essential, since without it
each user would be isolated on his or her own machine.
Nowadays users expect machines to be able to work coopera-
tively in a variety of modes ranging from mail and file
transfer to shared network services for printing and filing.
Manufacturers without adequate networking software are find-
ing it increasingly difficult to compete.
2.6. International Software
A final technology trend is towards international
software (programs or systems that can be used with many
different national languages). This trend is still not
well-established, but appears slowly to be taking hold. For
example, there is it at least one major manufacturer working
on an international version of the Unix operating system.
Another example is Apple's HyperCard system, which promises
eventually to support different languages through automatic
translation mechanisms.
3. Breakthrough Possibilities
Our second task as a subcommittee was to consider where
there might be major breakthroughs in software over the next
ten or fifteen years. By ``breakthrough'' we mean an
improvement of an order of magnitude in some important
metric, such as performance, cost, development time, or
error rate. Compared to some of the hardware areas being
considered by the committee as a whole, software appears
much less amenable to major breakthroughs. We do not anti-
cipate any advances equivalent to the relentless exponential
increase in component density that has occurred for
integrated circuits. Gains in software are likely to come
slowly, if at all. Nonetheless, there appear to be at least
three areas in which breakthroughs are possible: concurrent
programming, formal techniques, non-procedural languages,
and encryption.
3.1. Concurrent Programming
One of the trends in the design of high-performance
computers is towards greater degrees of parallelism (the use
of several functional units or processors, all operating at
the same time, to speed up the solution of certain prob-
lems). Current supercomputers, like the Cray machines, have
small degrees of parallelism, either in the form of pipelin-
ing (e.g. in the Cray-1) or multiple processors (e.g. the
Cray-2). Although there will be continuing advances in the
speed of individual processors, much more potential
February 22, 1988
- 5 -
performance improvement is possible if large numbers of pro-
cessors can be applied concurrently to solve a problem. A
few examples of highly-parallel machines are available today
(like those from Thinking Machines), and more examples are
likely to appear in the future.
The problem with highly parallel machines is how to
program them. Most existing software is written for a sin-
gle processor carrying out tasks sequentially. It is
extremely difficult to take a sequential program and subdi-
vide it so that different pieces may execute concurrently on
different processors. Some application areas appear well-
suited to parallelism, while others do not appear to map
conveniently onto concurrent machines. For parallel
machines to become widely used, new techniques must be
developed for programming them. The new techniques must be
accompanied by new development environments that allow effi-
cient concurrent programs to be produced quickly and easily.
Although this is an area of great importance, and one
in which a breakthrough would have major significance to the
computer field as a whole, it is not at all obvious that a
breakthrough will occur. Researchers have been working on
this problem for at least fifteen years without spectacular
results. Highly-concurrent programs have been developed for
a number of applications, but at great cost. The tools that
are currently available do not provide much assistance in
writing parallel programs. Overall, things don't seem a lot
better today than they did fifteen years ago.
On the other hand, there are probably more researchers
active in the field of concurrent programming now than ever
before, which will increase the likelihood of a break-
through. In addition, some recent developments, like the
Thinking Machines work, look promising, although it is still
too early to declare it a major breakthrough. A break-
through in the area of concurrent programming could result
in widespread use of machines with 10 to 100 times more pro-
cessing power than the machines most commonly available
today.
3.2. Formal Techniques
Another major focus of current research is in the
application of formal methods to software development.
Formal techniques can be applied in several ways. The most
rigorous approach is program verification: proof of func-
tional equivalence between a piece of code and a specifica-
tion of the code's intended behavior, or between a specifi-
cation and a set of requirements. Current technology allows
proofs between code and specification for up to 10,000 lines
of code, or between specification and requirements for up to
100,000 lines of specification, and the tools are emerging
from hand-craft to production quality. It is possible that
February 22, 1988
- 6 -
there may be major breakthroughs in this area by 1993-1995.
Even without proof of verification, formal techniques
can be applied to the development process, including, for
example, relational calculus, object-oriented design, well-
specified standards and interfaces, and strongly-typed
languages such as Ada, Modula, and Pascal. This trend can
potentially increase productivity by reducing the labor-
intensive post-design testing phase and the life-cycle
maintenance phase of software development. Semi-formal
techniques are already being applied to varying degrees in
many software development organizations.
This area is similar to concurrent programming in that
research efforts have been underway for almost 20 years,
with many disappointments and a few modest results to date.
It is possible that no major breakthrough will be forthcom-
ing. On the other hand, the technology appears to be gradu-
ally maturing; there are estimates that as much of 50% of
all software development will use formal techniques within
the next ten years. If verification techniques become
widely and successfully used in the software industry, they
could result in dramatic improvements in the reliability of
software and also in maintenance and testing costs.
3.3. Non-Procedural Languages
Some of the most exciting developments in software over
the last 10 years have consisted of new user interfaces
and/or ways of programming computers. Spreadsheet programs
are probably the best example of a successful new paradigm.
They represent a totally new way to manage and display
information in a computer, unlike anything that preceded
them. Spreadsheets also provide a novel programming
``language'' that is used to describe the relationships
between entries in the spreadsheet, so that a change in a
single entry can cause many other entries to be updated
automatically. This is a form of programming, but one that
is very different than a traditional programming language.
Another example of a novel programming paradigm is the
HyperCard system recently introduced by Apple. HyperCard
allows users to program the user interface by writing simple
procedures that describe the actions to take when buttons
are pushed or menu entries are selected. Once again, this
is a different way of programming than occurs in traditional
languages.
It is difficult to characterize the benefits that might
accrue from new programming paradigms, but it seems likely
that new paradigms will be invented in the next ten to fif-
teen years, and that these will revolutionize the way people
use computers in many application areas.
February 22, 1988
- 7 -
3.4. Encryption Services
User encryption services -- for integrity,
security/privacy, and authentication -- are just emerging
from government and university research laboratories. It is
possible that these will see widespread use in networks and
for software distribution over the next ten years. If a
breakthrough occurs, it could result in a substantial reduc-
tion in the penetrations and ``hacker attacks'' that have
occurred recently. Technology is not the limiting factor
here: the problem is to establish a coherent governmental
policy and to integrate the techniques into evolving net-
works and distribution channels. If encryption becomes
widely used, it could result in order-of-magnitude improve-
ments in the security of computer systems and permit comput-
ers to be used in more sensitive applications.
4. Major National Players
The subcommittee was unanimous in concluding that the
United States is the clear world leader in software. The
U.S. is the largest player, both in terms of production and
in terms of export, and is also the world leader in innova-
tion. The U.S. approach to software development appears to
be many years ahead of most other countries: for example,
the technology trend described in Section 2 above, towards
commoditization, standards, and software components, seems
to apply only to the U.S. Most other nations still carry
out software development in large organizations, producing
monolithic applications rather than components, much like
the U.S. did ten years ago. The United States appears to be
almost completely self-sufficient in software. We were not
able to identify any major areas where the U.S. imports
software.
On the other hand, there appears to be an increasing
interest in software around the globe, with many countries
explicitly targeting the software area. The outstanding
development tools developed in the U.S. will certainly
spread abroad, which may allow other countries (particularly
those with cheap labor) to compete in software development.
The sub-sections below survey the international scene to the
best of our knowledge. The information below is both incom-
plete and potentially inaccurate, and consists of opinions
collected from the committee members and their acquain-
tances.
4.1. Japan
The Japanese produce a large amount of software of gen-
erally very high quality. However, it is mostly produced by
large software organizations within large companies such as
NTT and Hitachi. Software tends not to be sold in unbundled
February 22, 1988
- 8 -
form and is usually marketed only as part of larger
hardware-software systems. Much of the Japanese software
development effort appears to be in embedded application
software for such products as banking systems, nuclear power
plants, and computer-aided design tools.
The quality of Japanese software is generally con-
sidered to be very high, perhaps even better than U.S.
software. It appears to be common for Japanese software
developers to work very closely with their customers and to
guarantee the quality of the software they produce. Such
guarantees are unheard of in the U.S.
Because of their current organizational structure the
Japanese do not currently appear to be a major threat to
U.S. dominance. For example, neither the Japanese 5th Gen-
eration project nor the TRON project appears to have pro-
duced any major breakthroughs. On the other hand, the
Japanese seem to do well at almost everything they try; if
they decide to target software and to restructure themselves
to export commodity packages (which doesn't seem to have
happened yet), they could become a major player.
4.2. Europe
On the research side, the European community has tended
to focus more on theoretical and formal approaches than on
practical system-building, so they have not produced many
interesting software systems. However, the British appear
to be more engineering-oriented in their research than the
rest of Europe; for example, the Computer Laboratory at
Cambridge University has produced many interesting hardware
and software systems.
On the industrial side, most software development
appears still to be carried out in large teams in large com-
panies, for internal use. There appear to be very few
software startups, perhaps due to the lack of venture capi-
tal.
However, the software situation appears to be changing
in Europe. Countries like France, which used to be more
theoretically oriented, are becoming more practical (e.g.,
the Ada language design, which originated with a French
team). Some software exports are beginning to occur, such
as Prolog, Ada, and software development environments. In
countries like Italy and Hungary, more smaller software com-
panies are forming. For example, in Italy there is quite a
bit of internal development of applications packages; how-
ever, the packages are mostly used within the country and
are not often exported.
February 22, 1988
- 9 -
4.3. Other Countries
A number of other countries are attempting to become
major players in the software market. Both Malaysia and
Taiwan have targeted software as major national priorities,
and several U.S. firms have offloaded some of their software
development effort to Taiwan because of cheap labor rates.
Some software development is also starting to occur in India
and Israel.
4.4. Is the U.S. Inherently Superior?
There is some evidence that the U.S. has fundamental
cultural advantages for producing software. Innovative
software seems to spring from entrepreneurial environments
consisting of a small number of dedicated, creative, and
uncontrolled individuals. The ready availability of venture
capital, and our societal structure as a whole, seem to nur-
ture such developments. Most of the rest of the world
appears to be much more rigidly structured, with large
industrial organizations, little venture capital, and,
often, no incentives for entrepreneurs to try radically dif-
ferent approaches. Such an environment does not seem condu-
cive to making software breakthroughs. For example, the
Japanese have been much less successful in penetrating the
software markets than they have been in other areas, in
spite of a few highly visible projects like the 5th-
Generation project and TRON.
On the other hand, there is also evidence that the U.S.
lead in software will be threatened in the future. Software
development requires more than just creativity; once the
initial idea has been generated, an enormous amount of work
is required to produce a reliable product. Software is most
likely to be of high quality if it is developed in a struc-
tured environment by skilled craftsman who carefully parti-
tion the work and manage interfaces. Although the U.S. cul-
ture appears well-suited to generating creative ideas, our
culture tends not to emphasize structure and craftsmanship,
which are essential in producing a software product. Other
countries with better organizational structure and crafts-
manship (e.g., Japan) may find that they can take ideas from
the U.S. and produce better software products.
Furthermore, software is very labor-intensive. This
may make it possible for countries with cheap labor (includ-
ing most of Asia) to compete effectively in the software
markets. There is already some evidence of this, such as
the offloading of software production to Taiwan.
5. The Soviet Union
In the software area the Soviets have both strong
February 22, 1988
- 10 -
cultural advantages and strong cultural disadvantages. On
the positive side, the Soviet Union has a large pool of
extremely talented mathematicians. Given the mathematical
nature of software development, the Soviets could be formid-
able competitors if they had the right tools and the right
environment. If software development becomes more heavily
driven by the use of formal techniques as described in Sec-
tion 3.2, the Soviets could have an advantage. On the nega-
tive side, the Soviets suffer from two almost insurmountable
disadvantages. First, they do not have a large community of
unsophisticated computer users, which means there is little
motivation for developing new software packages. Second,
the Soviet culture, with its rigid central controls and lack
of incentives, presents exactly the opposite of the
entrepreneurial environment that seems to foster software
creativity. These two problems make it unlikely that any
major software innovations will occur.
If the Soviet Union were to make available the kind of
environment that would foster software development (large
numbers of personal computers in the hands of many individu-
als throughout society), it might result in major structural
changes to their society. For example, it would be diffi-
cult to make good use of personal computers without effec-
tive networking (as we have discovered in the U.S.). But
good networking would make it impossible for any central
organization to control communications and the flow of
information (as we have also discovered). This might not be
acceptable to the Soviets. On the other hand, developments
like those that have occurred in the U.S. computer industry
cannot occur unless without widespread use of computers.
Our conclusion in Section 2 above was that the arrival of
the PC in million-unit quantities was the single greatest
driving force in recent U.S. software developments. Thus
the Soviets may be faced with a choice between a major
societal change and technological inferiority.
The current Soviet capabilities in several major
software areas are summarized below. In virtually every
area they lag substantially behind the rest of the world.
Most of their developments consist of importing, emulating,
and slightly enhancing Western packages. Note to committee
members: I'm only summarizing Bill McHenry's report here in
order to keep the length of this section proportional to the
report as a whole. However, we should probably include the
whole report as an appendix to the final report. Or, maybe
it even makes sense to insert it all in-line. Opinions?
Operating Systems. The Soviets are at least 10-15
years behind the times. They have made substantial
progress lately, but it all appears to consist of
imports or emulations of U.S. operating systems of the
1970's. Many centers still do not even have multipro-
gramming, and current mainframe operating system
February 22, 1988
- 11 -
capabilities do not seem to have progressed signifi-
cantly past IBM's 1973 level.
Programming Languages. Fortran and PL/I are apparently
the most commonly-used languages, although the Soviets
have recently obtained an Ada compiler. There is
apparently a major effort to develop parallel-
processing languages. The development of higher-level
languages (fourth-generation languages, spreadsheets,
etc.) has been hindered by the lack of a large user
community.
Databases. There appears to be quite a bit of interest
in databases in the Soviet Union, and a number of sys-
tems are available (many of them very similar to
Western systems). Nontheless, in more sophisticated
systems, such as relational systems and PC-based data-
bases, the U.S. is definitely ahead and the gap is
widening.
Software Development Environments. Soviet developments
here appear to be very crude. For example, interactive
editors are unsophisticated and interactive debuggers
are not always even interactive, let along symbolic.
Once again, the two problems are user community size
and central controls. Without a large unsophisticated
user community there is no incentive to develop power-
ful and easy-to-use tools. In a rigidly-controlled
environment, individuals and organizations are
encouraged to use existing tools rather than develop
new and better tools that deviate from national stan-
dards.
Artificial Intelligence. This has apparently been an
active area of research for many years, with most work
focussing on knowledge representation and natural
language processing. However, there appears to be no
coherent leadership or institutional support for AI;
much of the AI work appears to occur under the auspices
of some other discipline. Work in this area suffers
from lack of resources: for example, computer
resources are often at the level of the IBM PC or
worse, and there are few tools for building expert
systems.
6. Protectability
Our final task as a subcommittee was to consider the
issue of software protectability: can software be pro-
tected, and should it? Our conclusion is that it is virtu-
ally impossible to protect software. It is too widely
available, too easy to replicate, and too easy to conceal.
Diskettes not much larger than a credit card can hold all
February 22, 1988
- 12 -
the sources and binaries to a major software package; it
doesn't seem possible to prevent them from being carried and
copied all over the world. One of the best examples of the
difficulty of protecting software is the decision by several
key software manufacturers (including Lotus) not to copy-
protect their disks. The previous copy-protect mechanisms
were woefully inadequate and tended to alienate customers.
Instead, Lotus decided to rely on low-pricing and honest
customers, under the assumption that most customers would
prefer to pay a few dollars than to make an illegal copy and
risk trouble if discovered.
We recommend the same approach for international
software controls. It is futile to attempt to prevent the
spread of software, even to Eastern-block countries.
Instead, we think that software should be freely licensed
abroad so that U.S. companies can profit from the exports.
Those profits will go back into the U.S. economy, resulting
in further software developments and an increasing edge: a
positive spiral feeding itself. Our opinion is that most
conservative computing centers (e.g., all those in Eastern-
block countries) would prefer to purchase reasonably-priced
software than to risk being caught in a copyright or license
violation. If we make our software readily available to the
rest of the world, there will be less incentive for them to
develop their own software organizations; if U.S. software
is competitively priced, it will be harder for foreign
software organizations to generate revenues. On the other
hand, attempts to block software exports will not stop the
flow of information, but they will result in reduced exports
and profitability: a negative spiral feeding itself. If
U.S. software isn't reliably available abroad, it will
encourage the development and enhance the profitability of
foreign software organizations, which will eventually damage
the U.S. competitive position.
One possibile way of protecting software is to distri-
bute executable binaries only, and keep the human-readable
source code secret. Most major software companies do this
already. Without sources it is extremely difficult to
modify or enhance a program. However, the trend towards
standards is coming to include the distribution of sources
as well as binaries. For example, the X Window System is
distributed freely with sources, and there are thousands of
copies of the sources to the Unix operating system around
the country, even though they are all licensed by AT&T. If
source code is widely distributed then it cannot be pro-
tected against illegal export. Even within companies we
suspect that it is difficult to protect sources: too many
people have access and security is usually lax. A foreign
government with a major interest could almost certainly
obtain illegal copies of the sources. Once again, our
suggestion is to make it (slightly) easier for foreign coun-
tries to pay for software than to steal it.
February 22, 1988
- 13 -
The most effective way to prevent Western-block
software from being used on Eastern-block countries is to
deny the Eastern block countries access to the computers on
which to run the software. The computers are physically
more bulky, hence easier to spot during export. Even here,
though, continual miniaturization may make export controls
impractical.
Our committee was divided on whether encryption will
increase the protectability of software. One view is that
U.S. manufacturers must develop ``hacker-proof'' mechanisms
for preventing unauthorized use of software, and that
encryption techniques will lead to such mechanisms by the
mid-1990's. The opposing view is that any mechanism that
permits widespread distribution, no matter how controlled
that distribution appears to be, cannot be protected agains
theft by a dedicated opponent. For a package to be widely
distributed, the authority to grant access to that package
must also be widespread (e.g., among authorized distribu-
tors). With such widespread authority all it takes is one
dishonest dealer who will make copies for use in Eastern-
block countries.
7. Summary and Conclusion
The nature of software development in the U.S. has been
changed dramatically by the advent of personal computers.
Software is now developed in a decentralized fashion by hun-
dreds of companies, using standards and interoperable com-
ponents. The U.S. is currently the dominant international
player; virtually all other countries are still using the
centralized, monolithic approach to software development
that was common in the U.S. fifteen years ago. The Soviets
are particularly backward in the software area; without
major social changes (perestroika?) it appears unlikely that
they will be able to change this situation anytime soon.
Our conclusion is that the U.S. should not limit
software exports. On the contrary, we should encourage them
as much as possible, since this will fuel further growth of
the U.S. software industry and help to maintain our long-
term competitiveness.
February 22, 1988
∂22-Feb-88 1003 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [Nancy/Flora <COMMUNICATIONS@SUMEX-AIM.Stanford.EDU>: SIGLunch Announcement]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 10:03:42 PST
Date: Mon, 22 Feb 88 09:50:46 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: [Nancy/Flora <COMMUNICATIONS@SUMEX-AIM.Stanford.EDU>: SIGLunch Announcement]
To: nilsson@score.Stanford.EDU, jmc@sail.Stanford.EDU
Message-ID: <12376799599.67.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
NILS AND JOHN, I THINK THIS IS GOING TO BE A VERY GOOD AND PROVOCATIVE
TALK. BUT IF YOU WANT TO COME, COMNE A BIT EARLY, SAY 11:55am, TO BE SURE
TO GEET A SEAT. .....ED
---------------
Mail-From: COMMUNICATIONS created at 22-Feb-88 09:35:32
Date: Mon, 22 Feb 88 09:35:31 PST
From: Nancy/Flora <COMMUNICATIONS@SUMEX-AIM.Stanford.EDU>
Subject: SIGLunch Announcement
To: ksl@SUMEX-AIM.Stanford.EDU
Message-ID: <12376796824.26.COMMUNICATIONS@SUMEX-AIM.Stanford.EDU>
************************* SIGLunch Announcement ***************************
AI versus Common Sense:
The Case for Inelegance
Douglas B. Lenat
Principal Scientist, MCC
R. V. Guha
Member of the Technical Staff, MCC
Friday, February 26, 12:05pm
Chemistry Gazebo
In this talk, I would like to present a surprisingly compact, powerful,
elegant set of reasoning methods that form a set of first principles
which explain creativity, humor, and common sense reasoning -- a sort of
"Maxwell's Equations" of Thought. I'd like very much to present them,
but, sadly, I don't believe they exist. So, instead, I'll tell you what
I've been working on down in Texas for the last three years.
Intelligent behavior, especially in unexpected situations, requires
being able to fall back on general knowledge, and being able to
analogize to specific but far-flung knowledge. As Marvin Minsky has
said "the more we know, the more we can learn". Unfortunately, the
flip side of that comes into play every time we build
and run a program that doesn't know too much to begin with, especially
for tasks like semantic disambiguation of sentences, or open-ended
learning by analogy. So-called expert systems finesse this by
restricting their tasks so much that they can perform relatively narrow
symbol manipulations which nevertheless are interpreted meaningfully
(and, I admit, usefully) by human users. But such systems are
hopelessly brittle: they do not cope well with novelty, nor do they
communicate well with each other.
OK, so the mattress in the road to AI is Lack of Knowledge, and the
anti-mattress is Knowledge. But how much does a program need to know,
to begin with? The annoying, inelegant, but apparently true answer is:
a non-trivial fraction of consensus reality -- the few million things
that we all know, and that we assume everyone else knows. If I liken
the Stock Market to a roller-coaster, and you don't know what I mean, I
might liken it to a seesaw, or to a steel spring. If you still don't
know what I mean, I probably won't want to deal with you anymore.
It will take about two person-centuries to build up that KB, assuming
that we don't get stuck too badly on representation thorns along the
way. CYC -- my 1984-1994 project at MCC -- is an attempt to build that
KB. Some of the interesting issues are: how we decide what knowledge to
encode, and how we encode it; how we represent substances, parts, time,
space, belief, and counterfactuals; how CYC can access, compute,
inherit, deduce, or guess answers; how it computes and maintains
plausibility (a sibling of truth maintenance); and how we're going to
squeeze two person-centuries into the coming seven years, without having
the knowledge enterers' semantics "diverge".
We've gotten pretty far along already, and I figured it's time I shared
our progress, and our problems, with the HPP. Guha and I will stay
around after the talk, to go into more details for those of you who
are interested.
-------
-------
∂22-Feb-88 1230 @ai.toronto.edu:hector@ephemeral.ai.toronto.edu Computational Intelligence
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Feb 88 12:30:00 PST
Received: from ai.toronto.edu by RELAY.CS.NET id aa14532; 22 Feb 88 12:47 EST
Received: from ephemeral.ai.toronto.edu by ai.toronto.edu via ETHER with SMTP id AA27630; Mon, 22 Feb 88 12:08:52 EST
Received: from localhost (stdin) by ephemeral.ai.toronto.edu with SMTP id 27000; Mon, 22 Feb 88 12:07:17 EST
To: james@CS.ROCHESTER.EDU, bobrow@XEROX.COM, stefik@XEROX.COM,
kabowen@LOGICLAB.CIS.SYR.EDU, rjb@allegra.att.com, ec@cs.brown.edu,
dekleer.pa@XEROX.COM, jon.doyle@C.CS.CMU.EDU, forbus@P.CS.UIUC.EDU,
hayes.pa@XEROX.COM, hewitt@XX.LCS.MIT.EDU, hinton@C.CS.CMU.EDU,
hobbs@WARBUCKS.AI.SRI.COM, israel@WARBUCKS.AI.SRI.COM,
jmc@SAIL.STANFORD.EDU, val@SAIL.STANFORD.EDU, bmoore@WARBUCKS.AI.SRI.COM,
nilsson@SCORE.STANFORD.EDU, pentland@WARBUCKS.AI.SRI.COM,
watdaisy!dlpoole@math.waterloo.edu, reiter@ai.toronto.edu,
stan@WARBUCKS.AI.SRI.COM, stan%humus.bitnet@cunyvm.cuny.edu,
alberta!lksc@ubc-vision, briansmith@XEROX.COM,
stickel@WARBUCKS.AI.SRI.COM, tyson@WARBUCKS.AI.SRI.COM,
waldinger@KL.SRI.COM, winograd@CSLI.STANFORD.EDU,
woods@HARVARD.HARVARD.EDU, mcdermott-drew@YALE.ARPA
Subject: Computational Intelligence
Date: Mon, 22 Feb 88 12:07:20 EST
From: Hector Levesque <hector@ai.toronto.edu>
Message-Id: <88Feb22.120717est.27000@ephemeral.ai.toronto.edu>
I will be sending today out by normal mail (that is, to the extent that Canada
Post is normal) a copy of the special issue on McDermott's critique to
Allen, Brachman, Bowen, Charniak, de Kleer, Doyle, Forbus, Hewitt, Israel,
Kowalski, Lifschitz, Poole, Schubert, Woods, McDermott.
If your name is not on this list, please get your copy from the person on the
list at your institution. If your name is on the list, please distribute the
copies to the other contributors at your institution.
This will be my last message on this subject unless (until?) there are further
complications. Thanks again to everyone. Although things did not go as
smoothly as I would have liked, the issue is very readable, still interesting,
and, I hope you will agree, worth the trouble.
But may we never do this again!
Hector
∂22-Feb-88 1441 CLT calendar event
fri 18 mar 20:00 SFBallet (opera house)
∂22-Feb-88 1602 hearn%hilbert@rand-unix.ARPA Re: Draft software report
Received: from rand-unix.rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 22 Feb 88 16:01:53 PST
Received: by rand-unix.rand.org; Mon, 22 Feb 88 16:00:57 PST
Received: by hilbert.arpa; Mon, 22 Feb 88 15:58:22 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8802222358.AA19967@hilbert.arpa>
To: ouster%nutmeg.Berkeley.EDU@ginger.berkeley.edu (John Ousterhout)
Cc: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.ARPA,
jmc@sail.stanford.edu, mchenry@guvax.bitnet@rand-unix.ARPA
Cc: ouster@nutmeg.berkeley.edu
Subject: Re: Draft software report
In-Reply-To: Your message of Mon, 22 Feb 88 09:42:11 PST.
<8802221742.AA12322@nutmeg.Berkeley.EDU>
Date: Mon, 22 Feb 88 15:58:18 PST
John, thanks for the draft. It looks quite comprehensive, covering most
of the points that were raised. I'll give it a closer look later.
In the meantime, there's been some more discussion of the DES export issue.
I'm sending this to everyone since I sent the first one to them all.
Regards,
Tony
---------
Relay-Version: version B 2.10.2 9/5/84; site randvax.UUCP
Path: randvax!sdcrdcf!burdvax!psuvax1!gatech!mcnc!decvax!ucbvax!pasteur!ames!mailrus!umix!uunet!mnetor!utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: sci.crypt
Subject: Re: distribution of sensitive software like DES
Message-ID: <2275@geac.UUCP>
Date: 18 Feb 88 20:50:59 GMT
Date-Received: 21 Feb 88 15:58:56 GMT
References: <8801281211.AA13780@decwrl.dec.com> <8802162241.AA16997@armagnac.DEC.COM>
Reply-To: kent@DECWRL.DEC.COM
Followup-To: sci.crypt
Organization: /dev/redirection
Lines: 284
Summary: Crosposted...
This is a memo prepared by Digital's lawyers in response to John
Gilmore's note of last October. Please note that I am only passing this
along, without comment -- I know little if anything about the law, and
am not in the least interested in engaging in debate about this issue,
nor am I willing to pass such debate back to the lawyers piecemeal.
chris
--------Begin Forwarded Message
From: ehrgood@wnpv01.enet (TOM EHRGOOD, WNP, DTN 427-5698)
To: @cryptomemo.dis, ehrgood
Subject: Crypto Export Controls - Answer To Gilmore
_____________________________
| | | | | | | |
| d | i | g | i | t | a | l | I n t e r o f f i c e M e m o
|___|___|___|___|___|___|___|
TO: "TO" Distribution DATE: 16 February 1988
FROM: Tom Ehrgood
CC: "CC" Distribution DEPT: Corporate Law
TEL: (202) 383-5698
LOC: WNP
SUBJECT: Controls Over The Export Of Cryptographic Software
This memo answers points made in an October 27, 1987, memo by John
Gilmore, which we received on January 28th. Gilmore's memo, which I am
separately forwarding, argues that the posting of cryptographic software
to certain widely available bulletin boards places that software in the
"public domain," with the consequence that export licenses are not
required for the exports of that software. Gilmore's analysis has been
given wide distribution on various networks.
Gilmore is mistaken in his analysis and in his conclusion. Given the
high national security sensitivity of cryptography, generally, and DES
encryption, specifically, it is important to set the record straight.
The fundamental points that Gilmore gets wrong are:
o Exports of cryptographic software are governed by the State
Department's International Traffic in Arms Regulations ("ITAR"),
not by the Commerce Department's Export Administration
Regulations ("EAR"). Exports would be governed by Commerce's
EAR only if State waived jurisdiction.
o Although State Department regulations contain a "public domain"
exemption for technical data, cryptographic software does
not qualify as "technical data," and thus the "public domain"
exemption does not apply.
A legal analysis follows.
!
DISCUSSION
I. State Department Control Over Cryptographic Software
----------------------------------------------------
A. Cryptographic software is a "defense article"
---------------------------------------------
Section 38 of the Arms Export Control Act authorizes the President to
control the export and import of "defense articles" and "defense
services." This statutory authority -- which includes the authority to
to "designate those items which shall be considered as defense articles
and defense services" -- was delegated to the Department of
State, which in turn has implemented the statutory authority through
promulgation of the International Traffic in Arms Regulations ("ITAR"),
22 C.F.R. Subch. M.
The term "defense article" is defined in section 120.7 of ITAR to mean
"any item designated in section 121.1," which contains the United States
Munitions List.
Category XIII of the Munitions List provides in paragraph (b) as
follows:
Speech scramblers, privacy devices, CRYPTOGRAPHIC DEVICES AND
SOFTWARE (ENCODING AND DECODING), and components specifically
designed or modified therefore, ancillary equipment, and protective
apparatus specifically designed or modified for such devices,
components, and equipment. (Emphasis added.)
Since "cryptographic . . . software" is thus included on the United
States Munitions List, it is a "defense article" subject to the State
Department's ITAR controls over exports of such articles.
At certain low thresholds, it may not be clear whether software
containing certain encryption functionality in a technical sense
constitutes "cryptographic software" within the meaning of Category
XIII(b), above. Section 120.5 of ITAR establishes a procedure under
which "[t]he Office of Munitions Control will provide, upon written
request, a determination on whether a particular article is included on
the United States Munitions List." Questionable cases may be resolved
by following this procedure.
Assuming that encryption software does constitute "cryptographic
software" within the meaning of Category XIII(b), State Department
export licenses are required, REGARDLESS OF WHETHER THE ENCRYPTION IS
BASED ON THE DES ALGORITHM. The relevance of DES vs. non-DES lies in
the ease with which licenses can be obtained, not in whether licenses
are required.
B. The State Department's "public domain" exemption does not
apply to exports of "defense articles."
---------------------------------------------------------
Part 123 of ITAR contains rules governing export licenses for the export
of "defense articles." The basic rule is stated in Section 123.1(a) as
follows:
Any person who intends to export a defense article must obtain a
license from the Office of Munitions Control prior to the export
unless the export qualifies for an exemption under the provisions
of this Subchapter.
Part 123 sets forth a number of exemptions in sections 123.16 through
123.22. None is these exemptions covers the posting of cryptographic
software on a bulletin board.
Section 126.5 exempts from the licensing requirement any exports of
unclassified defense articles or unclassified technical data to Canada
for end-use in Canada or return to the United States. This exemption
would be potentially applicable only if the ONLY exports that might take
place as a result of the bulletin board posting were exports to Canada.
(See section 120.10, which defines "export" to include "[s]ending or
taking defense articles outside the United States in any manner.") In
any event, care would have to be taken to ensure that applicable
documentation requirements are met to invoke properly the exemption.
Part 125 of ITAR contains rules governing exports of technical data.
Section 125.1(a) provides:
The export controls of this part apply to the export of technical
data . . . . Information which is in the "public domain" (see
section 120.18) is not subject to the controls of this chapter.
Section 120.18 defines "public domain" as follows:
"Public domain" means information which is published AND WHICH
IS GENERALLY ACCESSIBLE TO THE PUBLIC:
(a) Through sales at newstands and bookstores;
(b) Through subscriptions which are available without restriction
to any individual who desires to obtain or purchase the published
information;
(c) Through second class mailing privileges granted by the U.S.
Government; or,
(d) At liberaries open to the public.
(Emphasis added.) This definition is a much more restrictive one than
the analogous Commerce GTDA regulation analyzed by Gilmore: a bulletin
board posting of information would not fall within ITAR's public domain
unless that posting qualified under paragraphs (a)-(d) of section
120.18. A posting would not appear to so qualify. (This memo does not
take any position on whether bulletin board posting would place
Commerce-controlled technical data into Commerce's public domain;
specific information about the technical data and the bulletin board
would be necessary.)
Regardless of how the ITAR "public domain" applies to bulletin board
postings in general, the posting of cryptographic software cannot fall
within the "public domain" provision, because, per section 125.1(a)
above, the "public domain" provision applies to "technical data."
Cryptographic software -- a "defense article" (see Section I.A above) --
does not constitute "technical data" under ITAR. More on that below.
The term "technical data" is defined in section 120.21 as follows:
"Technical data" means for purposes of this subchapter:
(a) Classified information relating to defense articles and
defense services;
(b) Information covered by an invention secrecy order;
(c) Information which is directly related to the design,
engineering, development, production, processing, manufacture,
use, operation, overhaul, repair, maintenance, modification, or
reconstruction of defense articles. This includes, for example,
information in the form of blueprints, drawings, photographs,
plans, instructions, computer software and documentation. This
also includes information which advances that state of the art of
articles on the U.S. Munitions List. This does not include
information concerning general scientific, mathematical or
engineering principles.
"Technical data" per this definition thus consists either of
information "relating to defense articles" (par. (a)) or information
directly related to the doing of things to "defense articles" (par. (c)).
[Paragraph (c) is not relevant here.] Since cryptographic software is
itself a "defense article," it cannot simultaneously qualify as
"technical data." Moreover, different ITAR Parts govern exports of
"defense articles" (Part 123) and exports of "technical data" (Part
125).
Of course, not all encryption materials (DES or otherwise) necessarily
take the form of "cryptographic software" controlled under Category
XIII(b) of the Munitions List. Non-Category XIII(b) materials will
qualify as "technical data" within the meaning of the section 120.21 and
will thus be eligible for "public domain" treatment if the specific ITAR
conditions apply.
II. Commerce Department Controls Over Cryptographic Software
--------------------------------------------------------
Section 370.10 of Commerce's Export Administration Regulations state the
general rule that Commerce does not control exports of State
Department-controlled items. Specifically, subsection (a) provides:
(a) U.S. Munitions List. Regulations administered by the Office of
Munitions Control, U.S. Department of State, Washington, D.C. 20520,
govern the export of defense articles and defense services on the U.S.
Munitions List.
Thus, Gilmore's statement that the State Department's concerns about
exports of crypt commands are "enforced" by Commerce is wrong.
What has complicated the picture and confused Gilmore is that Commerce's
Commodity Control List -- Commerce's counterpart to the United States
Munitions List -- contains a category 1527A covering "cryptographic
equipment . . . and software controlling or performing the function of
such cryptographic equipment." Gilmore identified this regulatory control
provision, but he misinterpreted it.
Gilmore found the note in category 1527A, which states that
Exporters requesting a validated license from the Department of
Commerce must provide a statement from the Department of State,
Office of Munitions Control, verifying that the equipment
intended for export is under the licensing jurisdiction of the
Department of Commerce.
Gilmore mistakingly says, however, that "we are not requesting a
validated license, we are using the general license, so this requirement
does not apply . . . ." Gilmore missed the 1527A heading: "Validated
License Required: Country Groups QSTVWYZ." These designated country
groups comprise every country in the world except Canada. Consequently,
a validated license issued by Commerce is required in order to make any
export of 1527A-controlled cryptographic software. And because a
validated license is required, exporters seeking such a license must,
per the note quoted above, submit a State Department statement
"verifying" that Commerce has jurisidiction over that cryptographic
software. Such a statement would generally take the form of an ITAR
section 120.5 commodity jurisdication determination.
In sum, unless the State Department has issued a statement verifying
Commerce jurisdiction over the cryptographic software that Gilmore has
in mind, Commerce's controls do not apply. And without such a
statement, Gilmore's analysis of section 379.3 of EAR (General License
GTDA) is completely irrelevant.
III. Conclusions
-----------
Gilmore's conclusion that the posting of cryptographic software to a
bulletin board places it in the public domain and thus exempts it from
export licensing controls is flat-out wrong. U.S. law is clear: in
order to export "cryptographic software" within the meaning of
Category XIII(b) of the United States Munitions List to any country
other than Canada, a State Department export license is required.
If there is any reason to believe or suspect that a non-U.S. or
non-Canadian national will gain access to that bulletin board, an export
to a third country should be assumed and a license is required..
If there is any question whether specific encryption software
constitutes "cryptographic software" within the meaning of
Category XIII(b), clarification can be obtained under procedures
established pursuant to section 120.5 of ITAR.
A determination from State under 120.5 that it does not have
jurisdiction is the prerequisite to bringing the control question into
Commerce's export regulations.
IT IS IMPERATIVE THAT NO DIGITAL EMPLOYEE ACT IN RELIANCE ON GILMORE'S
ANALYSIS OR HIS CONCLUSIONS.
∂23-Feb-88 1351 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
SEMANTIC APPROACH TO NONMONOTONIC LOGICS
(ONE YEAR LATER)
Yoav Shoham (SHOHAM@SCORE)
Stanford University
Friday, February 26, 3:15pm
MJH 301
1. In the past I proposed building nonmonotonic logics by associating
a partial order with models of a monotonic theory.
I first discuss possible generalizations:
1.1 We can consider relations on models that are not partial orders.
2.2 We can start with models of a nonmonotonic theory too, and by
"stacking" theories arrive at a notion subsuming stratified theories.
This is joint work with Allen Brown.
2. In the past I proposed the logic of chronological ignorance, a
nonmonotonic logic combining elements of temporal logic and
epistemic logic. I now discuss a generalization of it which
allows us to talk not only of when events took place, but also
how our beliefs about these occurrences change over time.
This is joint work with Fanzhen Lin and R. Michael Young.
∂23-Feb-88 1349 SJG reminder: Formfeed on Thursday
To: mugs@Score.Stanford.EDU, principia@Score.Stanford.EDU,
zabih@SUSHI.STANFORD.EDU, JMC@SAIL.Stanford.EDU,
VAL@SAIL.Stanford.EDU, shoham@Score.Stanford.EDU
Just a reminder that we'll be meeting for lunch in MJH 252 on Thursday
at noon. Come prepared to talk -- even if you have nothing concrete
to say!
Also, this is the *last* time I'll be sending this message to the
combined mailing list. From now on, I'll only send it to people who
either ask or show up ...
See you Thursday --
Matt
∂23-Feb-88 1359 CLT
jussi
∂23-Feb-88 1524 yuly@csv.rpi.edu
Received: from csv.rpi.edu (cs.rpi.edu) by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:24:30 PST
Received: by csv.rpi.edu (5.54/1.14)
id AA27475; Tue, 23 Feb 88 18:28:05 EST
Date: Tue, 23 Feb 88 18:28:05 EST
From: yuly@csv.rpi.edu (Liang-Yin Yu)
Message-Id: <8802232328.AA27475@csv.rpi.edu>
To: jmc@sail.stanford.edu
Dear Prof. McCarthy:
I have just finished a paper which put all the thought and theories
I have developed together. I would send it to you by post mail tomorrow.
However, since I wish to demonstrate the current stages of my research
to the admission committee, I hope it can be there in time. The paper
is typed in TeX form and the print-out spans about 20 pages. If you hold
the opinion that it is necessary for you or the committee to receive the
paper immediately, please notify me. I'll send it through e-mail, and
it is ready for printing. On the other hand, I presume that the paper
would arrive at Stanford in three days through post mail. If nothing
urgent happens, I tempt not to cram your computer memory.
Have a pleasant February.
Liang-Yin Yu
P.S. I am sure there are a lot of material in the paper that will interest
you. Please do take a look of it.
∂23-Feb-88 1544 helen@psych.Stanford.EDU Dinner Thursday, a problem I fear
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:44:31 PST
Received: by psych.Stanford.EDU (3.2/4.7); Tue, 23 Feb 88 15:41:25 PST
Date: Tue, 23 Feb 88 15:41:25 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Dinner Thursday, a problem I fear
Cc: helen@psych.Stanford.EDU
Hello there,
How was Paris? Ok, I hope.
I'm afraid this has turned out to be a difficult week. Toward the
end of the quarter, things like subject-running have to accelerate
and this week I've got four subjects X three hours each. I can't
run them on Friday afternoon or the weekend, so I've had to schedule
some for Thursday night. May we re-schedule our dinner for next
week sometime?
-helen
∂23-Feb-88 1726 VAL book
The following abstract from MENTAL.TEX[F76,JMC] is missing in the published
version of "Ascribing mental qualities to machines". Do we want to include it?
Ascribing mental qualities like $beliefs$, $intentions$ and $wants$
to a machine is sometimes correct if done conservatively and is sometimes
necessary to express what is known about its state. We propose some new
definitional tools for this: definitions relative to an approximate
theory and second order structural definitions.
∂23-Feb-88 1925 good@cli.com FINANCIAL AND TECHNICAL REPORTS
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 23 Feb 88 19:25:24 PST
Posted-Date: Tue, 23 Feb 88 21:15:42 CST
Received: from CLI.COM by vax.darpa.mil (5.54/5.51)
id AA13448; Tue, 23 Feb 88 22:22:12 EST
Received: by CLI.COM (4.0/1); Tue, 23 Feb 88 21:15:42 CST
Date: Tue, 23 Feb 88 21:15:42 CST
From: Donald I. Good <good@cli.com>
Message-Id: <8802240315.AA16800@CLI.COM>
To: SCHERLIS@vax.darpa.mil
Cc: SW-PI@vax.darpa.mil, wagner@cli.com, moore@cli.com, hunt@cli.com,
good@cli.com, boyer@cli.com, mksmith@cli.com
Subject: FINANCIAL AND TECHNICAL REPORTS
Bill,
Do you want us to file separate reports on Rose and Trusted Systems or
just one? Our contract requires separate financial information in
what we submit to the contracting officer.
dg
∂23-Feb-88 1928 gerry%eusip.edinburgh.ac.uk@nss.cs.ucl.ac.uk AAAI
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 19:27:52 PST
Received: from NSS.Cs.Ucl.AC.UK (TUNNEL.CS.UCL.AC.UK) by argus.Stanford.EDU with TCP; Tue, 23 Feb 88 19:27:35 PST
Received: from eusip.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08600; 23 Feb 88 17:38 GMT
From: Gerry Altmann <gerry%eusip.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Date: Tue, 23 Feb 88 17:35:55 GMT
Message-Id: <24087.8802231735@eusip.ed.ac.uk>
To: JMC%su-ai.stanford.edu@nss.cs.ucl.ac.uk
Subject: AAAI
Dear Professor McCarthy,
I am sorry it has taken me so long to get back to you, but I have been
away from Edinburgh for some time. I would just like to thank you for
your support in offering $6000 to help fund the workshop I am organising
on "Cognitive Models of Speech Processing: psycholinguistic and
computational perspectives". With this contribution from AAAI I have
now reached the financial target that I was aiming for. Interest in the
workshop has been widespread, and I anticipate a fruitful week. MIT
Press will be publishing the proceedings, and in addition, I shall
produce a report for inclusion in the AI Magazine.
With many thanks, once again,
Gerry Altmann
Centre for Speech Technology Research
University of Edinburgh.
∂24-Feb-88 0648 scherlis@vax.darpa.mil sw-pi
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 24 Feb 88 06:48:43 PST
Received: from sun45.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA14795; Wed, 24 Feb 88 09:48:20 EST
Posted-Date: Wed 24 Feb 88 09:42:51-EST
Received: by sun45.darpa.mil (5.54/5.51)
id AA25968; Wed, 24 Feb 88 09:42:53 EST
Date: Wed 24 Feb 88 09:42:51-EST
From: William L. Scherlis <SCHERLIS@vax.darpa.mil>
Subject: sw-pi
To: SW-PI@vax.darpa.mil
Message-Id: <572712171.0.SCHERLIS@VAX.DARPA.MIL>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
To avoid confusion: The address "sw-pi@vax.darpa.mil" is a mailing
list for the Software PI community. It is not an alias for Scherlis,
Squires, et al. (though we are on the list). If you have messages of
interest to the entire DARPA software community, feel free to use our
mailing list by mailing to sw-pi. (Mailing lists also exist for
architectures, distributed/parallel systems software, etc.)
Bill
-------
∂24-Feb-88 1324 CLT Financial info -- qlisp
To: Fenton@VAX.DARPA.MIL, Scherlis@VAX.DARPA.MIL
CC: IGS@SAIL.Stanford.EDU
CC: JMC@SAIL.Stanford.EDU
[This is my best guess as to the current state of the Qlisp contract
-- Stanford + Lucid component]
a. Arpa Order number, agent, and contract number.
Darpa order number: ????
Contract number: N00039-84-C-0211
Contracting agency: SPAWAR (Pucci)
b. Basic contract dollar amount.
$1912k
c. Dollar amounts and purposes of options, if any.
(na)
d. Start and end dates for task/contract.
7/15/86 - 1/15/88 with no cost extension to 5/31/88
e. Total spending authority received to date [ 2/23/87]
$1912k
f. Total spent to date [1/31/88]
$1470k
g. Monthly expenditure rate.
$84k (Stanford) + $50-55k (Lucid subcontract)
h. Any major non-salary expenses planned within this increment of funds.
Travel -- 2 roundtrip to France (Gabriel and Clinger)
Terminals and other onetime expenses 10k (Lucid)
i. Date next increment of funds is needed.
(na)
project mboxs = igs@sail.stanford.edu, jmc@sail.stanford.edu
∂24-Feb-88 1342 justeson@Portia.STANFORD.EDU letters of reference; 5 requests
Received: from Portia.STANFORD.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 13:42:47 PST
Received: by Portia.STANFORD.EDU (1.2/Ultrix2.0-B)
id AA16472; Wed, 24 Feb 88 13:44:21 pst
Date: Wed, 24 Feb 88 13:44:21 pst
From: justeson@Portia.STANFORD.EDU (John Justeson)
Message-Id: <8802242144.AA16472@Portia.STANFORD.EDU>
To: jmc@sail
Subject: letters of reference; 5 requests
ltr-of-ref.msg
∂24-Feb-88 2033 VAL book
The CBCL paper in your file ends with the words:
In order to make sense of expressions like those in the above
examples programs that use CBCL will have to be capable of
non-monotonic reasoning. Namely, they will need to be able to
give the most standard interpretations of the messages compatible
with what has been said explicitly. Circumscription has been
proposed as a tool for this.
The published version says instead:
Development of CBCL and implementation of programs using it is
being studied in collaboration with the Artificial Intelligence Center
of SRI international.
Which way do we want it?
∂25-Feb-88 0000 JMC
Call Robert Cohen.
∂25-Feb-88 0901 Qlisp-mailer Interchange with TAK: TAO and more
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 09:00:53 PST
Received: by labrea.Stanford.EDU; Thu, 25 Feb 88 08:22:19 PST
Received: from bhopal.lucid.com by edsel id AA26094g; Thu, 25 Feb 88 08:45:31 PST
Received: by bhopal id AA05777g; Thu, 25 Feb 88 08:51:18 PST
Date: Thu, 25 Feb 88 08:51:18 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802251651.AA05777@bhopal.lucid.com>
To: qlisp@sail.Stanford.EDU
Subject: Interchange with TAK: TAO and more
Ikuo Takeuchi and I carried on a somewhat lengthy correspondence after
my message about global variables. He is currently revising the TAO
language running of the ELIS machine. Perhaps someone else in the
Qlisp project will also find this interchange enlightening.
-------------------------------------------------------------------------------
Date: Thu 11 Feb 88 00:40:03
From: Ikuo Takeuchi <NUE@ntt-20.ntt.jp>
Subject: Re: timing Qlisp programs
To: edsel!jonl@LABREA.STANFORD.EDU
In-Reply-To: <8802080312.AA14024@bhopal.lucid.com>
Dear JonL
I've read your mail on QLisp-mailer, resent by H. G. Okuno to me. I'll
introduce you our current concepts of Lisp variables on a Lisp which
supports multi-processing and multi-users, which may be helpful for
your further consideration. The following is a translation of my series
articles on "A multiple paradigm language TAO" on a popular Japanese
Computer magazine "bit" (different from "BIT" in UK).
-----------------------------------------------------------------------------
Variables of TAO are slightly different from those of Common Lisp
because TAO supports multi-processing and multi-users, and also
supports logic programming like Prolog.
There are three classifications of TAO variables from different points
of view. First, variables are classified into Lisp variables and
logical variables. The latter is distinguished by prefixing "_" before
usual symbol name. (Indeed, they are different types of symbols.
Hereafter, however, I'll omit to mention logical variables.)
Second, variables are classified by their scope range, from near to
far, (1) local variable which can be seen only in the lexical scope
(but may be declared "special"), (2) instance variable which can be
deemed as local variables implicitly declared at the top of the body
if the function is a method corresponding to some message (it can't be
declared "special"), (3) special variable which can be accessible in
subsidiary function bodies called directly or indirectly from the
function which declares the variable "special", (4) semi-global
variable which is global within a process or a user's login as
described later, and (5) global variable which holds its value in its
value field.
The third classification reflects the representation of the variable
binding, and not essential to most users. (1) stack variable whose
value is held in the (hardware) stack, (2) BINDING variable whose
binding is represented by a dotted pair (called BINDING) of the value
and the variable name, (3) instance variable, the set of which is
packed in a vector representing a user defined object, (4) global
variable as described above.
Note that TAO's special variables should be declared in some program
constructs such as let, prog and function. Global variables can't be
bound, of course. They can only be SETQed and MAKUNBOUNDed.
The novel variables in TAO are semi-global ones. Semi-global
variables are further classified process-global variables and
login-global variables. A process-global variable is global only
within a process, and a login-global variable is global only within a
user's login which may creates a number of processes under it, of
course. In this terminology, the global variable can be called
package-global variable since its binding is global in the package of
the symbol.
To declare semi-global variables, use the following form:
(semi-globals [:process] aaa bbb ccc)
(semi-globals :login kkk jjj qwe asd)
where :process keyword can be omitted.
The difference of the meanings of special variables declared near the
top of the process initial function and process-global variables will
be clear if you consider the case when the process is reset
intentionally or accidentally. In that case, all special variable
bindings are lost, but process-global variable bindings remain, since
the latter are attached to the process object (in the object-oriented
programming sense). This difference is very crucial if those variables
contain such important things, say, editor buffers, conversation
history etc. Login-global variables can be deemed as usual global
variables for individual users.
By virtue of semi-global variables, it becomes very easy to share
the same program body among processes and users. However,
(package-)global variables and dynamically changeable property lists
of symbols are very dangerous for such purpose.
Local variables which are closed in a function closure, special
variables, semi-global variables are represented in the BINDING as
described above. (Locality and non-locality of the BINDING is
distinguished by a bit in the tag field.) Consequently, all such
variables can be explicitly closed in a function closure unlike Common
Lisp, thereby the user can control the range of variable sharability
among processes. For instance, if one makes a closure with a set of
special variables by:
(defmacro interprocess-closure (&rest vars)
`(closure ',vars #'(lambda (fn args) (apply fn args))) )
and gives it to the "interprocess-closure" slot of a number of process
objects, then the processes can share the variable bindings when they
are once reset and no other process does not. (Of course, fn will be
the "initial-function", and args will be the "initial-argument-list"
of the process.) If one knows the meaning of BINDING, he can freely
control the sharing of semi-global variables among processes.
(Probably, semaphores are the first shared variables.)
TAO obeys absolutely to the deep binding scheme because of its
suitability to the multi-processing. Variables are sought in the order
described in the second classification. However, instance variables in
a user defined object is hashed, and special, semi-global and global
variables are cached to access them efficiently. From our experience,
these hash and cache techniques overcome the inherent inefficiency of
the deep binding scheme and make the multi-processing with the shared
program and data feasible enough.
I agree with you in that global variables and special variable are
different kinds of things. If it is not properly recognized, it would
be very difficult to cope with multi-processing along the line of Common
Lisp.
Tak
-------
-------------------------------------------------------------------------------
Date: Thu, 11 Feb 88 20:16:06 EST
From: Jon L White <jonl>
To: labrea!NUE%ntt-20.ntt.jp
In-Reply-To: Ikuo Takeuchi's message of Thu 11 Feb 88 00:40:03 <12373630076.13.NUE@NTT-20.NTT.JP>
Subject: timing Qlisp programs
I think I received your letter directly.
It certainly looks like TAO has addressed all the concerns that I raised
in my 1985 note, and even a few more. The issue of Process-specific
global variables was raised at Xerox PARC during my time there with
the Interlisp-D group, but I don't think they actually did anything
with them. [Interlisp-D's deep binding scheme was just about good
enough, so that the performance difference between implementing process
globals and not implement them might not have been especially noticeable].
The issue of login-globals is new to me; is it patterned after shell
variables in Unix?
Would it be all right to forward you message describing variables in
TAO to other audiences here in the US? such as the QLISP group at
Stanford and possibly other groups involved in the ANSI standardization
of Common Lisp?
-- JonL --
-------------------------------------------------------------------------------
Date: Sat 13 Feb 88 00:32:53
From: Ikuo Takeuchi <NUE@ntt-20.ntt.jp>
Subject: Re: timing Qlisp programs
To: edsel!jonl@LABREA.STANFORD.EDU
In-Reply-To: <8802120416.AA10579@bhopal.lucid.com>
Dear JonL
I'm surprised to know my message reached you directly and I expect
this one will also reach you directly. (I'm not very familiar with the
mail system). Yes, of course, you can forward my message to all you
like, since the information is completely open. But I'm not
interested in the Lisp standardization as I said once to some people
in US before. I like Lisp because it is an ever evolving language
like natural languages which we use everyday and change according to
our needs whenever (but still remain as the same languages).
In fact, login-global variables were recently introduced into TAO. We
have extended the notion of the package to make it possible for users
or processes to share the same package, say, ZEN display editor after
Emacs, and TCP/IP network system. When a user (or process) uses such
a package, some process-global variables are declared at that time and
some package use linkage was established on the current package
(*package*).
However, it makes a kind of discrepancy between package use linkage
and semi-global variable declaration if a user makes more than one
processes under the same *package* and uses such a package only from
one process. In that case, you can see the symbols in the used
package within other processes but cannot use the package properly
because of the lack of semi-global variable declaration. Similar kind
of problem occurs if one process unuses a package, but some other
process still use it. These problems were revealed out in the window
system where each window corresponds to a process in principle. The
user implicitly assumes that his windows share some information and
computing environment such as package usage but do not share others.
The problem is obviously due to the independence between the package
designated by *package* (of each process) and the set of processes
created by a user. Our current, not quite satisfactory solution is to
introduce the login-global variables and the notion of special
packages, other than normal packages, which involve semi-global
variable declaration when to be used. Login-global variables are
sought just after process-global variables. (By the way, it should be
kept in mind not to abuse semi-global variables in sharable packages.)
Intern checks both the package use linkage of *package* and the
special-package-use-list slot of the current process.
At present, there are a few login-global variables, such as those for
the user's dictionary for Roman-to-Kanji transformation which conveys
the word usage frequencies and user customized word entries. The
user's dictionary is obviously login-wide and has to be updated in the
disk just once when the user is logged out, if he has ever used the
Japanese input facilities in his login.
(I'm not familiar with Unix because I've never used it seriously.
However, one of my colleagues told me that the login-global variable
is similar to the exported shell variable of the "B-shell".)
Tak
-------
-------------------------------------------------------------------------------
Date: Fri, 12 Feb 88 21:11:54 EST
From: Jon L White <jonl>
To: NUE@ntt-20.ntt.jp
In-Reply-To: Ikuo Takeuchi's message of Sat 13 Feb 88 00:32:53 <12374153059.10.NUE@NTT-20.NTT.JP>
Subject: timing Qlisp programs
It certainly looks like we have good network "turnaround"; I see that I am
now replying to your message three hours before you sent it! Notice that it
is still Friday, the 12'th of Feburary here. . . .
In this note you just sent me, you are describing what we fear may be
one of the big nightmares of multiprocessing -- indeterminancy in the
package system. Now, when you say
We have extended the notion of the package to make it possible for users
or processes to share the same package, say, ZEN display editor after
Emacs, and TCP/IP network system. When a user (or process) uses such
a package, some process-global variables are declared at that time and
some package use linkage was established on the current package
(*package*).
are you referring to the ZEN package as a Common Lisp package object? and
not simply meaning "package" in the more informal sense of "related set
of software"? I am assuming so. Also, I want to be sure that the
phrase "using a package" is in the technical sense of USE-PACKAGE:
However, it makes a kind of discrepancy between package use linkage
and semi-global variable declaration if a user makes more than one
processes under the same *package* and uses such a package only from
one process. In that case, you can see the symbols in the used
package within other processes but cannot use the package properly
because of the lack of semi-global variable declaration. Similar kind
of problem occurs if one process unuses a package, but some other
process still use it.
So are you describing the problems when two or more process cause
inconsistent updates to the package-use-list of a truly global package?
I have heard suggestions that package names have to be "made relative" to
work correctly on multi-processors; but I don't really understand what is
meant by that.
In our (Lucid's) implementation of Common Lisp, we have an underlying
vector for global linkages -- this is how compiled files can make
reference to certain pre-defined internal subroutines, and to system-
wide constants, parameters and semaphores. For Qlisp, some of these
"system-wide parameters, ..." had to be duplicated -- one private
copy for each processor. For example, the "current CONSing pointer"
is soon to be made processor-specific, so that the several processors
won't have to take the time to lock out others during the very
critical region of the CONS function.
It is a bit much to contemplate duplicating whole packages (in the
Common Lisp sense) so that each processor (or process!) can be
shielded from the random side-effects of other processes on USE-PACKAGE,
UNINTERN, etc.
I am also curious about what you call "interprocess-closures". In your
first note, you mention making some of them and
...[giving] it to the "interprocess-closure" slot of a number of process
objects, then the processes can share the variable bindings when they
are once reset and no other process does not.
What is this "interprocess-closure" slot of a process?
There has been some curiousity about TAO and ELIS in this country. I
wonder if you could collect some of your notes and letters [even the
electronic ones, like the notes to me] and write a short article for
the Lisp Pointers newsletter? It has circulation of about 1000, mostly
in the USA, but some in Europe and Japan. Like all newsletters, you
would retain the copyright to the material; also it is not refereed
except to pass the scrutiny of the Technical Articles Editor (that's me!),
so it could be ready for publication in the next issue, as soon as you
write it. Anyway, I think a descriptive article of between five and
fifteen pages would be very well received over here.
-- JonL --
-------------------------------------------------------------------------------
Date: Mon 15 Feb 88 18:17:03
From: Ikuo Takeuchi <NUE@ntt-20.ntt.jp>
Subject: Re: timing Qlisp programs
To: edsel!jonl@LABREA.STANFORD.EDU
In-Reply-To: <8802130511.AA13175@bhopal.lucid.com>
Dear JonL
. . .
Now, I have to answer your questions. First, as you noticed, my
wording was vague about using packages. In my last note, "package" is
used strictly in Common Lisp sense and so is "using a package". In our
system, each of ZEN, network and such subsystems correspond to a
Common Lisp package. Hence, my answer is "yes" to your second question
(So are you describing the problems when tow or more process cause
inconsistent updates to the package-use-list of a truly global
package?) But note that we are not addressing to multi-processors yet.
In a few years, however, we will experiment a multi-ELIS system. The
first version of multi-ELIS would not have shared memory.
In our current implementation, it is also dangerous to unintern a
symbol or to redefine a function in a global package which may be
used by a number of processes. However, from our experience, there
was little danger if the programmer responsible to the package updates
it while some other users use it. If it is anticipated dangerous, he
can make another global package of the same name safely. In that
case, it happens that some users use the old package and others use
the updated one at the same time!
The following is a snapshot of my top process at some moment (about 16:15
15-Feb-88) which was displayed and slightly well-formatted on the ZEN-shell
(a sort of Emacs-Interface Top Level). The machine Titanium is not equipped
with a bitmap display. Hence, no window processes are running on the machine.
Many of them are self-explanatory if you are familiar with the terminology of
ZetaLisp's processes. Here, "udo" stands for "User Defined Object".
Tao>(systat 'all)
[Titanium-Systat] load-min: 8% load-sec: 2% 15-Feb-88 16:17:08
Job Line Process Job Status Time Bottom
-------------------------------------------------------------------------------
3* 0 tak z running 0:11:02 15
5 1 imada top-level input-wait 0:00:04 14
7 4 osato top-level input-wait 0:06:54 11
8 3 nttit top-level input-wait 0:00:05 12
0 0 system interrupt-character mail-wait 0:00:37 0
1 0 system arp mail-wait 0:00:33 7
2 0 system tcp-out timer-wait 0:00:02 6
4 0 system ether fep-wait 0:00:03 8
6 0 system tcp-in mail-wait 0:00:43 5
Tao>[sys:current-process :describe]
{udo}621316[process], an object of class process (version 0),
has instance variable values:
sys:package {package}622468[tak]
sys:status #10
sys:whostate running
sys:priority 2
sys:wait-for-what (10)
sys:subsecond 0
sys:prestk-memblk-list ()
sys:sp {stkpt}#76216
sys:sbr #7002
sys:bottom-stack-block# 15
sys:semi-globals {vector}650289(bas:semi-global-variables . 134)
sys:variable-cache {vector}621187(sys:variable-cache . 256)
sys:quantum 5
sys:login {udo}622475[login]
sys:initial-function my-top
sys:initial-argument-list ({udo}40559[fundamental-stream]
{udo}40574[fundamental-stream] )
sys:interrupt-fn-args ()
sys:name univ:tak
sys:io ({udo}641865[net:telnet-client-stream]
{udo}40559[fundamental-stream]
{udo}40574[fundamental-stream] )
sys:pool {dnil}1067
sys:backtrace ((unbound-variable sys:curren-process nil)
vanilla-error backtrace-stopper)
sys:plist (sys:workbuf2 {memblk}2397785(#!8b-memblk . 1024)
sys:workbuf1 {memblk}2397608(#!8b-memblk . 1024)
:login-time 2780935089
:keyboard-idle 0)
sys:semaphores nil
sys:cpu-time 37478
sys:job "z"
sys:default-sysmode #4
sys:readtable {vector}621122(readtable . 128)
sys:readtable-sp {stkpt}#77400
sys:base-vector nil
sys:interprocess-closure nil
sys:error zen:zerror
sys:package-use-list ({package}42294[net]
{package}42327[jpro] ; Japanese input method package
{package}42316[zen] )
Tao>
As you can see, *package* and *readtable* are bound to the process
itself because of historical reason and efficiency. These slots, or
instance variables are as frequently synchronized with *package* and
*readtable* if the system has chance.
sys:status is a bit table representing the process status.
sys:prestk-memblk-list, sys:sp, sys:sbr (stack boundary register),
and sys:bottom-stack-block# are quite system internal variables.
ELIS's one quantum is 20millisecond.
sys:interrupt-fn-args holds the function and its argument list, if
any, which is to be executed (apply the function to its arguments) when the
interrupt is accepted.
sys:io holds all i/o streams the process is using.
sys:pool is a back pointer to the system process pool.
sys:backtrace holds the most recent error backtrace information.
sys:semaphores holds all the semaphores the process currently occupies.
sys:error holds the current error handling function.
sys:package-use-list holds the list of the currently used special
packages.
Now, I can answer your third question. When a process is created by
the function make-process, it is inert. As ZetaLisp, it is activated
by the function process-preset or process-reset. When a process is to
be activated, it's first action is normally to applying the initial
function to the initial argument list which are shown above. However,
if the "interprocess-closure" slot, or more precisely, the value of the
instance variable sys:interprocess-closure is not nil, it is applied
to the list of the initial function and the initial argument list.
For example,
(defun kkk (seeds)
(let (p1 p2 ic mb)
(declare (special mb))
(!mb (make-instance 'mailbox :name producer-consumer-channel))
(!ic (interprocess-closure mb))
(!p1 (make-process 'foo :initial-function 'produce
:initial-argument-list (list seeds)
:interprocess-closure ic ))
(!p2 (make-process 'bar :initial-function 'consume
:interprocess-closure ic ))
(process-reset p1)
(process-reset p2) ))
makes two processes get started, which are coupled and synchronized by
a mailbox named MB. Here, ! denotes a general assignment similar to
setf. Note that each process does not know the other process directly
by any means and they know only the channel between them by the shared
special variable MB, since the variables P1 and P2 are not passed to
the processes. If you run kkk twice, then there are two independent
sets of paired processes communicating each other. That is, the two
BINDINGs for MB are independent from each other.
Thanks for your kind invitation to the Lisp Pointers newsletter. I'm
not sure I could reply your invitation soon. Papers on TAO/ELIS become
obsolete soon after they are published, since it is my hobby to change
the language! TAO will be never completed! In addition, I'm still very
busy to develop our TAO/ELIS system. Especially to finish the real
time garbage collection is my this year's job. There is no problem
about opening our implementation techniques and experience, however.
Some day I'll try to submit them to the newsletter. Though I'm very
lazy to sum up and document all our jobs, I'm pleased to join
arguments on some specific topics if they are intersting to me and do
not take much my time.
Thanks, Tak
-------
-------------------------------------------------------------------------------
Date: Mon, 15 Feb 88 20:51:44 EST
From: Jon L White <jonl>
To: NUE@ntt-20.ntt.jp
In-Reply-To: Ikuo Takeuchi's message of Mon 15 Feb 88 18:17:03 <12374871072.23.NUE@NTT-20.NTT.JP>
Subject: timing Qlisp programs
Dear Tak,
. . .
Now back to TAO/ELIS. Thanks very much for your elucidation of package
terminology, process-closures and shared special variables; that cleared
up most of the questions I raised in the previous message. Didn't the
first Lisp Machines (and then "ZetaLisp") have functional closures that
would capture only a user-specified list of special variables? Was this
what influenced the TAO design, or did you independently arrive at the
need for some closuring over dynamic variables?
When we were designing VAX/NIL back in 1980, we used a representation
technique for special variables and for "captured" lexically-local
variables that was structurally the same; we could just as easily
close over any explicit set of variables, so we had the notion of
defaultly closing over all lexically visible variables (without having
to explicitly list them out), and over any explicitly-given list of
specials. The object-system primitives were fairly low-level, without
modeling any particular set of semantics for variables; but someone did
implement a flavors system that successfully permitted instance variables
to be special variables. [This representation of variables was discussed
in my paper in the 1982 ACM Lisp Conference].
I don't know that we had any particular applications in mind (other than
at least covering all the capabilities of MacLisp); we may have just
generalized for the sake of generalization. I am very eager to hear of
any experiences in system design that seem to need dynamic variable
constructs. As you well know, the Scheme influence has reduced the
tendency for Lisp programmers to use special variables, but it hasn't
entirely eliminated them.
You mention semaphores as "probably the first" construct to use
these process-closure dynamic variables. That means that such
variables are "semi-global [:process] ..." in your terminology, right?
That is, you wouldn't want the link to go away if the proces is reset.
Finally, about a Lisp Pointers paper: it's the universal complaint
of hackers that they are too busy working to write papers. I must
appreciate that complaint, since I invoke it myself frequently!
[and MacLisp was a classic case of a system that evolved too fast
to write a manual for, until it finaly "died"]. However, you are
clearly doing some very interesting stuff, and I'm sure many more
people would appreciate reading an overview type paper. The specific
issues of semantics for variables is something for which you may
have a unique contribution.
Once again, let me ask your permissing to circulate our series of
recent electronic messages to the QLISP group at Stanford. At the
very least, this group would be interested in the kinds of details
you have given. It may cause some of them to ask further questions
that I can't answer, so beware of a mail deluge (that's why I'm
asking again before re-circulating).
-- JonL --
-------------------------------------------------------------------------------
Date: Fri 19 Feb 88 16:32:38
From: Ikuo Takeuchi <NUE@ntt-20.ntt.jp>
Subject: Re: timing Qlisp programs
To: edsel!jonl@LABREA.STANFORD.EDU
In-Reply-To: <8802160451.AA17706@bhopal.lucid.com>
Dear JonL
. . .
As you pointed out correctly, the function "closure" is just what
ZetaLisp had. And we found that the "closure" is very suitable to the
multi-processing environment.
To make our variable system clearer, I'd like to describe how we
designed the TAO interpreter on the basis of the ELIS Lisp machine
which was independently designed from any Lisp language. In fact, the
design and construction of the ELIS Lisp machine started in 1978 and
the design of the TAO language on it started in 1981. The designer of
the ELIS, Mr. Hibino was thinking he would have to implement some Lisp
on it by himself! However, H. G. Okuno, N. Ohsato who, as you might
know, stayed at KSL to help H. G. Okuno for a half year in 1987, and
me got started to design a new language on it in 1981.
First, we chose the deep binding scheme because of its superiority
with respect to the multi-processing. Then, we decided to adopt the
single stack implementation, that is, control stack and value stack
are merged into one stack. (The single stack implementation is also
suitable for multi-processing. However, we encountered some
difficulties when we decided to implement the logic programming
features on TAO, since typical Prolong implementation uses three stacks
to maintain local, global and backtrack information. H. G. Okuno was
responsible to the logic programming features of TAO. Hence, he could
say much about it.)
Since ELIS has a fast stack memory whose access is as fast as the
internal registers if its top is accessed sequentially. After some
LAP code design prototyping, we decided to adopt the stack
representation of variable values instead of register representation
which most Lisp compilers on commercial machines adopt. Hence, the
typical frame structure corresponding to a function invocation looks
like as follows, where upper part (with lower address) is near to the
stack top:
+------------------+
| value of varN |
+------------------+
| .... | values for variables the for function
+------------------+
| value of var2 |
+------------------+
| value of var1 |
+------------------+
| | The size of aux information varies from 0 to 4
| frame aux info | depending of the kind of the function.
| | It determines the offset of the value slot.
+------------------+
| tf | top frame link (control link)
+------------------+
| ef | environment frame link (the frame is pointed to here)
+------------------+
| applobj | applobj (applicative object) = function in CL
+------------------+
| original form | preserves the original form, if any
+------------------+
| micro return addr|
+------------------+
The original form slot may be used for other purposes. To search for
the value of a given variable, the system refers to the table attached
to the applobj which holds its variables and its types (such as
obligatory, optional, etc) in order. It is slightly slower than the
implementation like Interlisp where variable names and values are
pushed on the stack in pairs. However, the frame structure is
compiler-oriented but it maintains all the necessary information for
the interpreter and debugger (especially, for backtrace function
because all lexical variables can be named somehow even they are
compiled). In our implementation, preprocessing of S-expression
function bodies be invisible pointers is extensively used to speed up
the lexical variable access. That is, information on the offset
within a frame and the number of environment frames to be
chain-followed is embedded in a form invisibly to the user. This
technique makes the interpretation of typical programs 10 to 30
percent. (Some simple benchmarks gain 70 percent speed up, however.)
In the native TAO, variables are changed to be "special" by the
function (not the declaration) "special-variables" as follows:
(special-variables VAR1 VAR2 ...)
which replaces the value slot of each variable in the frame by a
BINDING:
(VALUE . VAR)
which is pointed to by a tag {splvar} with some special tag bit on.
(In our system, a Lisp pointer has 8 bit tag field. 6 of 8 is used to
distinguish the data type. Another one bit called "tage" (for tage
extension, pronounced as Tah-Gay) is used to extend the meaning of the
6 bit data type tag. The rest one bit is used specially, but mainly
for garbage collection.) And if a variable is "captured" by a
function closure, it is also replaced by the same form of BINDING
which is also pointed to by the tag {splvar} with the special tag bit
(tage) on or off, according that the captured variable is special or
not.
I think that the above explanation gives enough information to
understand and guess how our variable system is constructed with
relation to the function closure, binding scheme etc. We could
emulate CL's lambda relatively easily.
I think that Lisp programmers should use dynamic variables in some
disciplined manner, but need not be forced not to use them. Lisp
compiler written in Lisp itself is a good example on the issue how to
use dynamic variables in such a big program. Lisp compiler has to
maintain the information structure corresponding to the nesting of
various Lisp control constructs. All of them can be passed as
parameters to subfunctions of the compiler somehow, but it is
obviously cumbersome style of programming I think. Infrequent
switching of flags or states is well represented by nested dynamic
variables. In the context of multi-processing, the notion of shared
dynamic variable will be important.
You wrote:
> You mention semaphores as "probably the first" construct to use
> these process-closure dynamic variables. That means that such
> variables are "semi-global [:process] ..." in your terminology, right?
> That is, you wouldn't want the link to go away if the process is reset.
But it is not right partly. "Captured" special variables in the
interprocess-closure are not process-global variables, though they are
very similar in their semantics; both are not vanished when the
process is reset. They are different in their internal representation,
and if there are two variables of the same name both in
interprocess-closure and process-global semi-global variable vector,
the former is always prior to the latter in the variable search.
In our system, process reset has happened quite a few times because of
unknown bugs in the front end processor such as I/O jam and network
trouble, bugs in the system, bugs in user programs and user's explicit
keyboard interrupts. The user can interrupt his program and "throw"
to the top-level by hitting control-\. (By the way, this throw needs
a function (throwablep catch-tag) before it actually does throw, since
there may not be the catch tag which corresponds to the top-level loop
in some cases.) And the double hitting of control-\ make his process
reset. Alas, many users tend to hit control-\ many times when their
programs seem to have gone out of control. Our protection against
accidental process reset has such history.
It might be careless to mention semaphores as "probably the first"
variables which are to be shared by processes. There are two more
useful process communication primitives implemented in microcode,
which do not need semaphore control: mailbox for passing any kind of
Lisp data between processes and pipe-stream for passing text data
between processes, which can be used just as usual I/O streams. The
following system defined function "process-peep" illustrates the usage
of the mailbox.
(defun process-peep (process &optional (fn 'backtrace) args &aux mailbox)
(!mailbox (make-instance 'mailbox :name 'peeper))
(process-interrupt process
#'(lambda (m fn args)
(send-mail m (catch 'error (apply fn args))) )
(list mailbox fn args)
t )
(receive-mail mailbox) )
which reports the backtrace information of other process
asynchronously if all optional variables are defaulted. This function
is quite useful when a process seems to fall in some out-of-control
state.
Other our outstanding experience on the concurrent-programming
includes the implementation of TCP/IP network system in TAO written by
Ken'ichiro Murakami and an experiment of Distributed and Coordinated
Problem Solving in TAO written by Rikio Onai. In the former, the
hierarchical TCP/IP network layers are associated with a class
hierarchy of network daemons. Thus, it can be deemed one of the first
instances which combine the concurrent programming and object-oriented
programming in a practical sense. The latter is of quite experimental
nature. However, it explored some techniques about the concurrent
programming in Lisp. For examples, it was found that "shared special
logical variable" can be used as a kind of test-and-set variable
between processes, since the unification has just such nature. And it
was also found that process-interrupt capability is quite useful to
avoid deadlocks in the parallel problem solving. I expect those
experiences and techniques will be summarized in a form of technical
papers soon by the individual authors.
Thanks again for your encouragement to write something about our
experience. I'd like to do my best on the matter. However, as I like
to say, following the great Chinese Philosopher Lao-Tze,
"The TAO which is called the TAO is not the true TAO."
I'm afraid nothing is completely steady in TAO yet. Indeed, I'm
planning to change the TAO native lambda to be dedicated to the
downward funarg, which involves some drastic change in the language
kernel, and call the current function closure to be the general one as
it is. The downward funarg dedicated lambda seems to be more
efficiently implemented than the general closure. Of course, it will
cause an error, if it is conveyed upward or sideways (that is, across
processes) and to be invoked.
"Once again," I can say that my mail is quite open to anyone who is
interested in such matters. But, OOOO..PS, I'm afraid the "DELUGE" (I
had to refer to my dictionary to understand this word). I guess some
of the questions can be answered well by H. G. Okuno, though he doesn't
seem to know some recent changes in TAO. However, any question is
welcome that influences me on clobbering the future TAO.
Thanks, Tak
-------
-------------------------------------------------------------------------------
∂25-Feb-88 1248 @po2.andrew.cmu.edu:lb0q+@andrew.cmu.edu Workshop sponsored by AAAI?
Received: from po2.andrew.cmu.edu by SAIL.Stanford.EDU with TCP; 25 Feb 88 12:48:12 PST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA03339> for jmc@sail.stanford.edu; Thu, 25 Feb 88 15:48:33 EST
Received: via switchmail; Thu, 25 Feb 88 15:48:31 -0500 (EST)
Received: FROM export.andrew.cmu.edu VIA qmail
ID </cmu/common/mailqs/q006/QF.export.andrew.cmu.edu.22248be5.85344>;
Thu, 25 Feb 88 15:47:38 -0500 (EST)
Received: FROM export.andrew.cmu.edu VIA qmail
ID </cmu/cdec/lb0q/.Outgoing/QF.export.andrew.cmu.edu.22248bc7.7a1244>;
Thu, 25 Feb 88 15:47:05 -0500 (EST)
Received: from Sendmessage.5.22.CUILIB.3.40.SNAP.NOT.LINKED.export.andrew.cmu.edu.ibm032
via MS.3.66.export.andrew.cmu.edu.ibm032;
Thu, 25 Feb 88 15:47:03 -0500 (EST)
Message-Id: <sW98j7y00VQ2wYE05Z@andrew.cmu.edu>
Date: Thu, 25 Feb 88 15:47:03 -0500 (EST)
From: Leslie Burkholder <lb0q+@andrew.cmu.edu>
To: jmc@sail.stanford.edu
Subject: Workshop sponsored by AAAI?
Cc: Leslie Burkholder <lb0q+@andrew.cmu.edu>
I wish to apply for a grant to sponsor a workshop on semantic tableau theorem
provers. The idea is to bring together several individuals working in this
area and many logic instructors, primarily in philosophy departments, who
teach this method of theorem proving. The workshop will be held in conjunction
with the third annual computers and philosophy conference. The workshop has
two goals: (1) to promote exchange among researchers in this area, and (2) to
explain to logic instructors what has been done in such a way that they can
make some use of it. These researchers do not seem to get together: they are
scattered about the globe, some in the US, some in Canada, some in the UK, and
some in Australia. The instructors do not seem to have made any use of recent
research in this area, largely because they are unaware of its existence. The
grant will be used to cover the travel expenses of the participants in the
workshop who would not normally attend the Computers & Philosophy Conference.
Budget
Travel expenses for five people: US$4000.
Subject
Semantic tableau theorem provers: procedures for making them more efficient.
Participation
There will be two kinds of participants. Most of the participants will be
attendees at the Computers & Philosophy Conference. The other participants are
by and large people who would not normally attend the Computers & Philosophy
conference. Many of these have done work on semantic tableau theorem provers.
When and where
Dartmouth College, Hanover, NH. August 1988.
Program committee
Leslie Burkholder, CDEC CMU.
Randy Dipert, SUNY/Fredonia.
Austen Clark, University of Tulsa.
Leslie Burkholder
∂25-Feb-88 1415 Mailer failed mail returned
In processing the following command:
MAIL
The following message was aborted because of a command error,
namely, nonexistent recipient(s):
lb0q
------- Begin undelivered message: -------
25-Feb-88 1415 JMC +@andrew.cmu.edu
re: Workshop sponsored by AAAI?
[In reply to message sent Thu, 25 Feb 88 15:47:03 -0500.]
I am no longer running the AAAI workshop program. Please send your request
to Peter Hart, HART@SRI.COM and also to aaai-office@sumex.stanford.edu.
------- End undelivered message -------
∂25-Feb-88 1425 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 14:24:42 PST
Date: Thu 25 Feb 88 14:18:09-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12377634707.24.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
February 26: Dr. Joseph Y. Halpern (IBM San Jose),
"Knowledge and Common Knowledge in a Distributed Environment"
March 4: Dr. Phokion G. Kolaitis (Stanford Univ.),
"The Expressive Power of Database Query Languages"
-------
∂25-Feb-88 1429 Qlisp-mailer new-qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 14:29:31 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06503; Thu, 25 Feb 88 14:30:15 pst
Received: by labrea.Stanford.EDU; Thu, 25 Feb 88 13:50:30 PST
Received: from kolyma.lucid.com by edsel id AA27446g; Thu, 25 Feb 88 14:18:30 PST
Received: by kolyma id AA10795g; Thu, 25 Feb 88 14:27:41 PST
Date: Thu, 25 Feb 88 14:27:41 PST
From: Carol Sexton <edsel!carol@labrea.Stanford.EDU>
Message-Id: <8802252227.AA10795@kolyma.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp
I'll be installing a new new-qlisp this afternoon. This lisp has
includes
some small improvements to the deep-binding code. Old binary files
Old binary files won't
load correctly into this new lisp so you'll have to recompile your files
in order to use the new new-qlisp.
Carol
∂25-Feb-88 1451 STAGER@Score.Stanford.EDU 1988/89 Courses and Degrees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 14:51:08 PST
Date: Thu 25 Feb 88 14:46:56-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: 1988/89 Courses and Degrees
To: jmc@Sail.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12377639948.49.STAGER@Score.Stanford.EDU>
Have you had an opportunity to review the course descriptions for CS309
and CS350 yet? I realize that organizing the industrial lectureships can
be time consuming, but am hoping that I'll receive your updated copy within
the next day or two. Editing deadline is early next week.
Thanks again.
Claire
-------
∂25-Feb-88 1610 BEDIT@Score.Stanford.EDU Summary of January computer charges.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 16:10:23 PST
Date: Thu 25 Feb 88 15:26:26-PST
From: Billing Editor <BEDIT@Score.Stanford.EDU>
Subject: Summary of January computer charges.
To: MCCARTHY@Score.Stanford.EDU
Message-ID: <12377647138.18.BEDIT@Score.Stanford.EDU>
Dear Mr. McCarthy,
Following is a summary of your computer charges for January.
Account System Billed Pct Cpu Job Disk Print Adj Total
JMC SAIL 2-DMA705T 100 336.92 281.75 ***.** 10.71 5.00 3067.68
MCCARTHY SCORE 2-DMA705T 100 .00 .00 6.88 .00 5.00 11.88
MCCARTHY SUSHI SUSHI 100 .00 .00 .00 .00 .00 .00
Total: 336.92 281.75 ***.** 10.71 10.00 3079.56
University budget accounts billed above include the following.
Account Principal Investigator Title
2-DMA705 McCarthy N00039-84-C-0211
The preceding statement is a condensed version of the detailed summary sheet
sent monthly to your department.
Please verify each month that the proper university budget accounts are paying
for your computer usage. Please also check the list of account numbers below
the numeric totals. If the organizations/people associated with that account
number should NOT be paying for your computer time, send mail to BEDIT@SCORE.
Please direct questions/comments to BEDIT@SCORE.
-------
∂25-Feb-88 1808 hayes.pa@Xerox.COM Re: Summary of January computer charges.
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Feb 88 18:08:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 FEB 88 18:08:46 PST
Date: 25 Feb 88 18:08 PST
From: hayes.pa@Xerox.COM
Subject: Re: Summary of January computer charges.
In-reply-to: Billing Editor <BEDIT@Score.Stanford.EDU>'s message of Thu, 25 Feb
88 15:15:44 PST
To: BEDIT@Score.Stanford.EDU
cc: Hayes.pa@Xerox.COM, JMC@sail.stanford.edu
Message-ID: <880225-180846-3328@Xerox>
>Dear Pat Hayes,
>
>Following is a summary of your computer charges for >January.
>
>Account System Billed Pct Cpu Job Disk Print >Adj Total
>
>PJH SAIL 2-DMA705T 100 .00 .00 7.19 .00 >5.00 12.19
>
>Total: .00 .00 7.19 .00 5.00 >12.19
>
>University budget accounts billed above include the >following.
>Account Principal Investigator Title
>
>2-DMA705 McCarthy N00039-84-C-0211
I asked for my account to be closed some time ago, and was assured that it had
been. When will the charges stop? I have not logged in to the system since
September, and I should have no disc usage now. Are you charging me for the
recollection of what I used to be?
Pat Hayes
∂25-Feb-88 1812 rivin@Gang-of-Four.Stanford.EDU letter of interest to symbolics
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 18:12:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA07706; Thu, 25 Feb 88 18:12:49 pst
Date: Thu, 25 Feb 88 18:12:49 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802260212.AA07706@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: letter of interest to symbolics
Here is a draft of the letter of interest to Symbolics re their
multiprocessor. They would like to have it by the 29th, so if you can
get it out tomorrow, they would certainly be happy. Of course, if you
feel that it would be OK for me to sign it, that would be fine also.
In any case, what do you think of the contents?
\documentstyle[12pt]{letter}
\address{Professor John McCarthy\\Margaret Jacks Hall\\Stanford University
\\Stanford CA 94305}
\signature{John McCarthy}
\begin{document}
\begin{letter}{Carl White\\Symbolics, Inc.}
\opening{Dear Mr. White,}
The QLISP project at Stanford University would like to thank you and
Dr. Shrobe for your informative presentation of the Symbolics
multiprocessing effort and for your hospitality.
We are interested, in principle, in joining the Symbolic
Multiprocessing Consortium. We do, however, have some concerns that we
would like to see addressed if we do, in fact, join.
Since our project's interest is in evaluating the feasibility of a
certain multiprocessing Lisp paradigm, we would like to see extensive
tools for analysing the performance of concurrent programs. These
tools should hopefully be more extensive then the (single-processor)
metering tools presently available under the Symbolics Genera 7.1.
Secondly, we would like to be confident that the Symbolics
multiprocessor supports all of the Qlisp language constructs. The
thorniest issue at present seems to be the non-local exit mechanism
via CATCH/THROW and the garbage collection of processes that that
entails.
Thirdly, one of the main reasons why we might want to switch from an
existing multi-processor machine to the Symbolics multiprocessor is
the historic superiority of the the Symbolics software environment --
we would like to have some confidence that this will still be the case
for the multiprocessor.
Fourthly, we would like to see a version of the multiprocessor with
more than eight processors as soon as possible, as it is not possible
to evaluate many parallel algorithms adequately on as few as eight
processors.
We suspect that these concerns are not unlike those of the other
potential members.
\closing{Sincerely,}
\end{letter}
\end{document}
∂25-Feb-88 2102 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
SEMANTIC APPROACH TO NONMONOTONIC LOGICS
(ONE YEAR LATER)
Yoav Shoham (SHOHAM@SCORE)
Stanford University
Friday, February 26, 3:15pm
MJH 301
1. In the past I proposed building nonmonotonic logics by associating
a partial order with models of a monotonic theory.
I first discuss possible generalizations:
1.1 We can consider relations on models that are not partial orders.
2.2 We can start with models of a nonmonotonic theory too, and by
"stacking" theories arrive at a notion subsuming stratified theories.
This is joint work with Allen Brown.
2. In the past I proposed the logic of chronological ignorance, a
nonmonotonic logic combining elements of temporal logic and
epistemic logic. I now discuss a generalization of it which
allows us to talk not only of when events took place, but also
how our beliefs about these occurrences change over time.
This is joint work with Fanzhen Lin and R. Michael Young.
∂26-Feb-88 1126 nilsson@Tenaya.stanford.edu [APPELT@SRI-WARBUCKS.ARPA: [Margaret Olender <olender@malibu.ai.sri.com>: UPCOMING TALK
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 26 Feb 88 11:26:44 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00146; Fri, 26 Feb 88 11:27:04 PST
Date: Fri, 26 Feb 88 11:27:04 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802261927.AA00146@Tenaya.stanford.edu>
To: jmc@sail
Subject: [APPELT@SRI-WARBUCKS.ARPA: [Margaret Olender <olender@malibu.ai.sri.com>: UPCOMING TALK
BY LEORA MORGENSTER]]
This talk seems related to a discussion you and I had recently. -N
----
Return-Path: <@Score.stanford.edu:APPELT@WARBUCKS.AI.SRI.COM>
Date: Fri 26 Feb 88 08:37:03-PST
From: Doug Appelt <APPELT@SRI-WARBUCKS.ARPA>
Subject: [Margaret Olender <olender@malibu.ai.sri.com>: UPCOMING TALK
BY LEORA MORGENSTER]
To: Nilsson@SCORE.stanford.edu
In-Reply-To: <8802250119.AA04366@Gang-of-Four.Stanford.EDU>
Nils,
You and others in principia might find this talk interesting.
- Doug
---------------
Return-Path: <@malibu:olender@malibu.ai.sri.com>
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
25 Feb 88 14:36:25-PST
Received: by malibu (3.2/4.16) id AA04622 for aic-staff@warbucks; Thu,
25 Feb 88 14:36:28 PST
Date: Thu, 25 Feb 88 14:36:28 PST
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8802252236.AA04622@malibu>
To: aic-staff@warbucks
Subject: UPCOMING TALK BY LEORA MORGENSTERN / BROWN UNIVERSITY.
WHEN: FRIDAY, MARCH 4th
TIME: 10:30am
WHERE: EJ228
SPEAKER: LEORA MORGENSTERN / BROWN UNIVERSITY.
WHY THINGS GO WRONG:
A FORMAL THEORY OF PREDICTION AND EXPLANATION
Leora Morgenstern
Brown University
This talk presents a theory of Generalized Temporal Reasoning. We focus
on the related problems of:
(1) Temporal Projection - figuring out all the facts that are true
in some chronicle, given a partial description of that chronicle
and
(2) Explanation - figuring out what went wrong if an expected
outcome didn't occur.
Standard logics can't handle temporal projection due to such problems
as the frame problem (and qualification problem). Simplistic
applications of non-monotonic logics also won't do the trick, as the
Yale Shooting Problem demonstrates. During the past several years, a
number of solutions have been proposed to the Yale Shooting Problem,
which either use extensions of default logics (Shoham,Kautz), or which
circumscribe over predicates specific to a theory of action
(Lifschitz, Haugh). We show that these solutions - while perfectly
valid for the Yale Shooting Problem - cannot handle the general
temporal projection problem, because they all handle either forward or
backward projection improperly.
We present a solution to the generalized temporal projection problem
based on the notion that actions only happen if they are *motivated*.
We handle the non-monotonicity using only preference criteria on
models, and avoid both modal operators and circumscription axioms. We
show that our theory handles both forward projection and backward
projection properly, and in particular solves the Yale Shooting
Problem and a set of benchmark problems which other theories can't
handle. An advantage of our approach is that it lends itself to an
intuitive model for the explanation task. We present such a model,
give several characterizations of explanation within that model, and
show that these characterizations are equivalent.
This talk reports on joint work done with Lynn Stein of Brown
University.
-------
-------
∂26-Feb-88 1321 helen@psych.Stanford.EDU Re: dinner
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 13:21:20 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 26 Feb 88 13:18:05 PST
Date: Fri, 26 Feb 88 13:18:05 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: Re: dinner
Ok, let's say next Tuesday evening. Say, 6 p.m.?
-helen
∂26-Feb-88 1723 Qlisp-mailer meeting
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 17:23:33 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00665; Fri, 26 Feb 88 17:24:22 pst
Date: Fri, 26 Feb 88 17:24:22 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8802270124.AA00665@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: meeting
Will be held this wednesday, March 2, in MJH 301, at noon. The agenda
will include a discussion of Ron's CATCH/THROW proposal and current
business of all flavors.
Igor
∂26-Feb-88 1737 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Reminder
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 17:36:40 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA12244; Fri, 26 Feb 88 17:35:30 PST
Date: Fri, 26 Feb 88 17:35:30 PST
From: ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU (John Ousterhout)
Message-Id: <8802270135.AA12244@nutmeg.Berkeley.EDU>
To: cweissman@dockmaster.arpa, hearn@rand-unix.arpa, jmc@sail.stanford.edu,
mchenry@guvax.BITNET, ouster@nutmeg.Berkeley.EDU
Subject: Reminder
Don't forget: I need to have all your comments on the software
subcommittee draft report by this coming Monday, 2/29. Thanks in
advance.
-John-
∂26-Feb-88 1847 binford@Boa-Constrictor.Stanford.EDU Joe Engelberger
Received: from Boa-Constrictor.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 18:47:21 PST
Received: by Boa-Constrictor.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA11162; Fri, 26 Feb 88 18:45:14 PST
Date: Fri, 26 Feb 88 18:45:14 PST
From: binford@Boa-Constrictor.stanford.edu (Tom Binford)
Message-Id: <8802270245.AA11162@Boa-Constrictor.Stanford.EDU.stanford.edu>
To: jmc@sail
Subject: Joe Engelberger
John
This note is to remind you to look up Joe's
telephone number.
You might be interested to know that I have been
working with an MD on some vision applications in
medical practice. Theis work is serious to help out,
and build something, not really to pursue funding.
Tom
∂26-Feb-88 2005 BRINK@Sushi.Stanford.EDU Letter of Recommendation (or the opposite)
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 20:05:47 PST
Date: Fri 26 Feb 88 20:01:39-PST
From: Ed Brink <brink@Sushi.Stanford.EDU>
Subject: Letter of Recommendation (or the opposite)
To: jmc@Sail.Stanford.EDU
Message-ID: <12377959383.12.BRINK@Sushi.Stanford.EDU>
I don't know whether you are planning to write anything to go with my
application for the PhD. The choice is yours, of course; but I just got a note
from Graduate Admissions saying you and one other recommender had not yet
responded.
You might let me know whether you intend to write or not, so I'll keep bugging
you in the one case and quit in the other.
Thanks.
..Ed
-------
∂27-Feb-88 0820 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu requested response
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Feb 88 08:20:49 PST
Received: by lindy.stanford.edu; Sat, 27 Feb 88 08:22:05 PST
Received: by Forsythe.Stanford.EDU; Sat, 27 Feb 88 08:20:01 PST
Date: Sat, 27 Feb 88 09:57 EST
From: <MCHENRY%GUVAX.BITNET@forsythe.stanford.edu> (I would not be convicted by a jury of my p...)
Subject: requested response
To: JMC@sail.stanford.edu
X-Original-To: @jmc,@cweissman,@blumenthal,@goodman
Distribution-File:
JMC@sail.stanford.edu
CWEISSMAN@dockmaster.arpa
BLUMENTHAL@a.isi.edu
GOODMAN%uamis@rvax.ccit.arizona.edu
Gentlemen: I have given John a few editorial suggestions below and then
have some more thoughts about the protectability section of the draft.
Bill McHenry, 2/27/88
Here are a few minor things that you can search and replace on:
"situation on Russia" : we should refer to the Soviet Union only as the
Soviet Union or the USSR. Russia is now only the name of the largest
republic.
"Soviets are far behind the rest of the world" : too general. They lag the
Western industrial nations, but are far ahead of LDCs and the really poor
nations.
"X window" needs an s.
"interfaces is that the allow" - they allow
"The result is that very little software was developed" is should be was.
"Nonetheless, there appear to be at least three" - and then you mention 4.
"monolothic" --> monolithic
The report reads well and you have done a good job of synthesizing our
contributions. It is clear that we need more input on what is happening
around the world.
I would not say that most of the Soviet developments (p10) come from
stealing or emulating the West. I would say many of the more important ones
have.
I am not sure that we can just say that because it is too hard to control,
we should loosen all export control regulations on software. The micro
explosion is indeed bringing about the mass distribution of software as a
commodity. But, there are concrete limitations on what can be accomplished
on a micro. There are many important applications that still require the
largest available mainframes, e.g. airline reservations. While there may be
software development environments for micros which are quite cheap, they
are still a far cry from the much larger set of tools used for building
large systems, e.g. a C3I system of some sort. The breakthru technologies
will not initially be available for micros and will not be commodities.
We are primarily focusing on systems software. Applications software is
somewhat different because there we are more clearly just selling a
capability to the Soviets. Packages which have the potential for dual-use
still require variable degrees of adaptation to their new use and if sold
in object code only, may be quite difficult to modify. Systems software, on
the other hand, gives the Soviets the ability to build whatever large
systems they want and need. Leading edge tools need to be protected. The
Soviets may get them eventually, but we still slow them down. Can we put
together a short list of highly important packages?, such as:
- expert system shells with important problem-solving algorithms
- certain kinds of knowledge bases themselves (e.g. one which drives CASE
tools)
- software validation tools including proof of correctness tools
- complete software development environments which have integrated tool
sets and typically function in environments which build large-scale systems
- "true" solutions for distributed processing
- compilers which adapt linear code sequences for parallel processing
- 4th generation languages
(These mainly follow from the list of breakthru technologies we have
identified.)
Protectability. Software is not just the diskette with the object or even
the source code. It is also a product which is tailored to a specific
set of requirements, it is a product with support and training - in other
words we should not view software in isolation from what goes with it.
Eastern block computer centers may prefer to buy software directly, but
they don't particularly have access to hard currency in order to do so.
Even if all of Gorbachev's perestroyka reforms are culminated, I doubt we
will see a fungible currency from Eastern Europe. The Soviets are likely to
follow the same path they have: acquire the software from the West, make
some modifications as necessary (add a Cyrillic front-end, for example),
and distribute it for virtually nothing to those who purchase hardware.
Selling the software directly to the Soviets simply means that this
process will be initiated sooner. Of course foreign governments will
eventually find ways to get their hands on software, but at greater expense
and without the surrounding environment. Plus once the software arrives
there, it has a different status than it would had it been purchased
legally. The use of the package cannot be publicized and is probably
classified, the user groups may be restricted, and all sorts of other
controls put into place which erect desirable barriers. We still come back
to the idea that putting more links in the chain helps to slow down the
Soviets.
It is conceivable that a few computer centers will have the hard currency
to buy, but then this isn't much of a market, is it? It is inconceivable
that there will be a large Soviet market for US software products such as
dBase III+, where millions of copies are shipped all over the USSR. This is
not necessarily because the demand is not there, although it is not there
now and cannot be there for at least five years while the Soviets still get
their micro act together, but also because there simply is not that kind of
widespread availability of hard currency. In addition, removing all
controls will potentially unleash the entrepreneurial, ideal small US firm
to write applications directly for Soviet customers. Direct legal sales to
Soviet customers will result in maintenance and training, which in itself
constitutes considerable technology transfer.
We can deny the Soviets some hardware, but they have shown themselves
capable of building functional duplications themselves of major machine
architectures. This means that an export control policy based only on
denial of hardware will just give the Soviets even stronger incentives to
duplicate our machines.
Where is the main area of agreement between software vendors and export
control policy-makers? It is in the desire for fool proof schemes to
prevent unauthorized duplication of software. I throw out the following
idea for discussion. A very important recommendation should be the
necessity of spending what it takes to link software to specific machines
in a way that makes vendor intervention necessary if the product is moved
to another machine. We are not talking about products which are commodities
along the lines of dBase III+, but stuff on our "short list." (Vendors
themselves may use such mechanisms for all their software anyway because
they do not want unauthorized duplication as well. It can be argued that
conservative computer center directors will be willing to put up with this
restriction, and that if comparable software is available from Japan or
elswhere without protection, that protection is not likely to be the single
basis for the purchase decision - price and support will be.) Part of the
licensing agreement will be that the buyer may not re-export to banned
countries, but instead of having to apply for a license, the vendor will be
responsible for enforcing this regulation. Vendors who do not enforce it
will incur severe penalties. This means that vendors will have the free
ability to ship almost everything without having to apply for a license per
se, although there will have to be some classification which goes on to
establish where a package fits into the "short list." There will be no
re-export restrictions except to banned countries. And we have given
vendors themselves a reasonably non-intrusive intervention point at which
this single re-export restriction can be enforced. There may still be
packages which leak through because of distributors who hold the keys and
can be bought, etc., but that is a fact of life. Our goal is still to slow
down the Soviet military.
∂27-Feb-88 0821 MCHENRY%GUVAX.BITNET@forsythe.stanford.edu requested response
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Feb 88 08:21:07 PST
Received: by lindy.stanford.edu; Sat, 27 Feb 88 08:22:26 PST
Received: by Forsythe.Stanford.EDU; Sat, 27 Feb 88 08:20:38 PST
Date: Sat, 27 Feb 88 09:55 EST
From: <MCHENRY%GUVAX.BITNET@forsythe.stanford.edu> (I would not be convicted by a jury of my p...)
Subject: requested response
To: JMC@sail.stanford.edu
X-Original-To: @sw
Distribution-File:
@ouster,@hearn,@jmc,@cweissman,@blumenthal,@goodman
ouster%nutmeg.Berkeley.EDU@jade.berkeley.edu
HEARN@rand-unix.arpa
JMC@sail.stanford.edu
CWEISSMAN@dockmaster.arpa
BLUMENTHAL@a.isi.edu
GOODMAN%uamis@rvax.ccit.arizona.edu
Gentlemen: I have given John a few editorial suggestions below and then
have some more thoughts about the protectability section of the draft.
Bill McHenry, 2/27/88
Here are a few minor things that you can search and replace on:
"situation on Russia" : we should refer to the Soviet Union only as the
Soviet Union or the USSR. Russia is now only the name of the largest
republic.
"Soviets are far behind the rest of the world" : too general. They lag the
Western industrial nations, but are far ahead of LDCs and the really poor
nations.
"X window" needs an s.
"interfaces is that the allow" - they allow
"The result is that very little software was developed" is should be was.
"Nonetheless, there appear to be at least three" - and then you mention 4.
"monolothic" --> monolithic
The report reads well and you have done a good job of synthesizing our
contributions. It is clear that we need more input on what is happening
around the world.
I would not say that most of the Soviet developments (p10) come from
stealing or emulating the West. I would say many of the more important ones
have.
I am not sure that we can just say that because it is too hard to control,
we should loosen all export control regulations on software. The micro
explosion is indeed bringing about the mass distribution of software as a
commodity. But, there are concrete limitations on what can be accomplished
on a micro. There are many important applications that still require the
largest available mainframes, e.g. airline reservations. While there may be
software development environments for micros which are quite cheap, they
are still a far cry from the much larger set of tools used for building
large systems, e.g. a C3I system of some sort. The breakthru technologies
will not initially be available for micros and will not be commodities.
We are primarily focusing on systems software. Applications software is
somewhat different because there we are more clearly just selling a
capability to the Soviets. Packages which have the potential for dual-use
still require variable degrees of adaptation to their new use and if sold
in object code only, may be quite difficult to modify. Systems software, on
the other hand, gives the Soviets the ability to build whatever large
systems they want and need. Leading edge tools need to be protected. The
Soviets may get them eventually, but we still slow them down. Can we put
together a short list of highly important packages?, such as:
- expert system shells with important problem-solving algorithms
- certain kinds of knowledge bases themselves (e.g. one which drives CASE
tools)
- software validation tools including proof of correctness tools
- complete software development environments which have integrated tool
sets and typically function in environments which build large-scale systems
- "true" solutions for distributed processing
- compilers which adapt linear code sequences for parallel processing
- 4th generation languages
(These mainly follow from the list of breakthru technologies we have
identified.)
Protectability. Software is not just the diskette with the object or even
the source code. It is also a product which is tailored to a specific
set of requirements, it is a product with support and training - in other
words we should not view software in isolation from what goes with it.
Eastern block computer centers may prefer to buy software directly, but
they don't particularly have access to hard currency in order to do so.
Even if all of Gorbachev's perestroyka reforms are culminated, I doubt we
will see a fungible currency from Eastern Europe. The Soviets are likely to
follow the same path they have: acquire the software from the West, make
some modifications as necessary (add a Cyrillic front-end, for example),
and distribute it for virtually nothing to those who purchase hardware.
Selling the software directly to the Soviets simply means that this
process will be initiated sooner. Of course foreign governments will
eventually find ways to get their hands on software, but at greater expense
and without the surrounding environment. Plus once the software arrives
there, it has a different status than it would had it been purchased
legally. The use of the package cannot be publicized and is probably
classified, the user groups may be restricted, and all sorts of other
controls put into place which erect desirable barriers. We still come back
to the idea that putting more links in the chain helps to slow down the
Soviets.
It is conceivable that a few computer centers will have the hard currency
to buy, but then this isn't much of a market, is it? It is inconceivable
that there will be a large Soviet market for US software products such as
dBase III+, where millions of copies are shipped all over the USSR. This is
not necessarily because the demand is not there, although it is not there
now and cannot be there for at least five years while the Soviets still get
their micro act together, but also because there simply is not that kind of
widespread availability of hard currency. In addition, removing all
controls will potentially unleash the entrepreneurial, ideal small US firm
to write applications directly for Soviet customers. Direct legal sales to
Soviet customers will result in maintenance and training, which in itself
constitutes considerable technology transfer.
We can deny the Soviets some hardware, but they have shown themselves
capable of building functional duplications themselves of major machine
architectures. This means that an export control policy based only on
denial of hardware will just give the Soviets even stronger incentives to
duplicate our machines.
Where is the main area of agreement between software vendors and export
control policy-makers? It is in the desire for fool proof schemes to
prevent unauthorized duplication of software. I throw out the following
idea for discussion. A very important recommendation should be the
necessity of spending what it takes to link software to specific machines
in a way that makes vendor intervention necessary if the product is moved
to another machine. We are not talking about products which are commodities
along the lines of dBase III+, but stuff on our "short list." (Vendors
themselves may use such mechanisms for all their software anyway because
they do not want unauthorized duplication as well. It can be argued that
conservative computer center directors will be willing to put up with this
restriction, and that if comparable software is available from Japan or
elswhere without protection, that protection is not likely to be the single
basis for the purchase decision - price and support will be.) Part of the
licensing agreement will be that the buyer may not re-export to banned
countries, but instead of having to apply for a license, the vendor will be
responsible for enforcing this regulation. Vendors who do not enforce it
will incur severe penalties. This means that vendors will have the free
ability to ship almost everything without having to apply for a license per
se, although there will have to be some classification which goes on to
establish where a package fits into the "short list." There will be no
re-export restrictions except to banned countries. And we have given
vendors themselves a reasonably non-intrusive intervention point at which
this single re-export restriction can be enforced. There may still be
packages which leak through because of distributors who hold the keys and
can be bought, etc., but that is a fact of life. Our goal is still to slow
down the Soviet military.
∂27-Feb-88 0930 JMC
Cohen
∂27-Feb-88 0958 hearn%hilbert@rand-unix.ARPA Re: requested response
Received: from rand-unix.rand.org (RAND-UNIX.ARPA) by SAIL.Stanford.EDU with TCP; 27 Feb 88 09:58:24 PST
Received: by rand-unix.rand.org; Sat, 27 Feb 88 09:08:18 PST
Received: by hilbert.arpa; Sat, 27 Feb 88 09:05:15 pst
From: Tony Hearn <hearn%hilbert@rand-unix.ARPA>
Message-Id: <8802271705.AA27520@hilbert.arpa>
To: MCHENRY%GUVAX.BITNET@cunyvm.cuny.edu
Cc: ouster@nutmeg.berkeley.edu
Cc: HEARN@rand-unix.ARPA
Cc: JMC@sail.stanford.edu
Cc: CWEISSMAN@dockmaster.arpa
Cc: BLUMENTHAL@a.isi.edu
Cc: GOODMAN%uamis@rvax.ccit.arizona.edu
Subject: Re: requested response
In-Reply-To: Your message of Sat, 27 Feb 88 09:55 EST.
<8802271559.AA06994@rand-unix.rand.org>
Date: Sat, 27 Feb 88 09:05:12 PST
I agree with Jim that John has done a good job summarizing our inputs.
It's certainly good enough for us to use at the next meeting. However, I
can see that we need a lot more discussion on the software issue. I guess
we'll have to wait for the meeting to thrash all that out. A few points
though:
1) In my limited experiences in dealing with the scientific sector, I've
found the Soviets wanting to play the game by the rules. The question is
whether that extends to a wider sector.
2) There was something I read in one of the trade newspapers recently
about Microsoft being in Moscow trying to set up a deal, but being
frustrated at the moment by the fact that the Soviets haven't yet recognized
the fact that software can be copyrighted. That's why I thought it might
be in the U.S.'s interests to push the Soviets to recognize some protection
for software.
3) Maybe we need to distinguish "commodity software" from other types. The
former is all the stuff that people are now selling in large quantities
(*including* compilers, tool kits and the like). This stuff is like books.
And notice that the Soviets have seemed to behave on the question of book
copyrights. Anything that's not in this class is presumably of value to
the developer, and will probably be distributed without sources and thus
hard to reverse engineer. Does anyone think the commodity class
can/should be controlled?
4) Statements about the power of today's micros should be replaced by
statements about the micros that will be available in five to ten years.
After all, if we hope that this report will help develop policy, we want
it to influence things for some years to come. Even if today's micros
can't run sophisticated applications, the RISC micros of tomorrow will
(forgetting for the moment about the needs for a distributed network for
some applications).
A final anecdotal story: JINR, Dubna, recently bought some hardware to
set up a local area network (at 9600 baud, by the way). However, they chose
not to buy the software, because of the cost and the fact that they have a
lot of people with little to do (since everyone's employed, right?) who
could write the software. The system's running, and they are quite happy
with it (after all 9600 baud beats carrying tapes around).
∂27-Feb-88 1408 ARK SAIL out of CSD-CF
To: JMC@SAIL.Stanford.EDU
CC: IGS@SAIL.Stanford.EDU, JSW@SAIL.Stanford.EDU,
ARK@SAIL.Stanford.EDU
I wholeheartedly endorse the idea of taking SAIL out of CSD-CF. Gio and I
and our group have been spending as much as $10K/year (about 4%, I would
guess), and I would be interested in having us buy some appropriate
fraction of SAIL and not have to worry about my use of connect time and
disk space. I'd also be willing to devote a small amount of
administrative time of approving budgets and such if you were uninterested
in doing that.
My guestimate is that the current SAIL budget of $250K/year could be cut
in about half by taking SAIL out of CSD-CF. We would need all of Marty,
half of Don Coates, and pay-by-the-hour usage of hardware help when
needed, as well as network charges. Any additional hardware needed could
be paid out of grant funds, which would save us the overhead on the
depreciation otherwise incurred.
Arthur
∂27-Feb-88 1730 hirani@jessica.Stanford.EDU Job
Received: from jessica.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 17:29:58 PST
Received: by jessica.Stanford.EDU; Sat, 27 Feb 88 17:28:50 PST
Date: 27 Feb 1988 1728-PST (Saturday)
From: Anil Hirani <hirani@jessica.Stanford.EDU>
To: jmc@sail.Stanford.EDU
Cc:
Subject: Job
Professor McCarthy
I graduated in January 1988 with an MS in CS from Stanford. I am interested
in a full time programming job in theorem proving, logic programming
or related areas. Does the EKL group have any openings for full time
programmers ? If you are interseted I could send you my resume.
Sincerely
Anil Hirani
∂27-Feb-88 2321 RDZ@Score.Stanford.EDU The latest AIList
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 23:21:08 PST
Date: Sat 27 Feb 88 23:17:00-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: The latest AIList
To: jmc@Sail.Stanford.EDU
Message-ID: <12378257089.12.RDZ@Score.Stanford.EDU>
has a long, rambling flaky opinion piece, some of which seems to be a
response to your Daedalus article.
Ramin
-------
∂28-Feb-88 0004 RDZ@Score.Stanford.EDU re: The latest AIList
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 00:04:11 PST
Date: Sun 28 Feb 88 00:00:02-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: re: The latest AIList
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sat 27 Feb 88 23:58:00-PST
Message-ID: <12378264922.12.RDZ@Score.Stanford.EDU>
Yes, the article seemed to have quite a few inaccuracies. For example,
David Baltimore is at MIT, not Harvard.
Ramin
-------
∂28-Feb-88 1612 RPG ISLISP
The Japanese and Canada voted with the US on every issue the first time
the issues came up. In fact, we heard Ito tell the others that he
overheard our private voting comments and recommended they vote as he
thought we would. Most of the rest followed on the second ballot. (I
spent 4 hours with Ito after you left.)
On characteristics of the language:
portable
clear semantics
simple semantics
efficient
in roughly that order. The AFNOR list is:
modules/packages fixed
simple generic function extensions
dynamic-let instead of (let ((x ...)) (declare (special x))...)
no dynamic extent objects (I'm not sure what they mean here)
simplified type system with respect to arrays
strict function type
simplified keyword structure in lambda-lists
separation of libraries for selective linkage
international character set provisions
Most of their proposal is reasonable, but not necessary. That is,
they want to implement a C-like Lisp system and feel they need a new
Lisp to do it, whereas the truth is that they simply need to do
a little different implementation strategy with minor extensions to
Common Lisp.
The alternative for ISLISP was International Standard Lisp, but we felt
it would be nicknamed ISO Lisp, so we suggested ISLISP. Also, the US
voted 1/2 for Common Lisp and 1/2 for Scheme as starting points. The US
did not volunteer to do any work aside from project editorship.
EuLisp seems a dead issue.
The Japanese felt they got everything they wanted and the Europeans felt
they got screwed by the better debating style of the US delegation.
I'll be coming into Stanford tomorrow to discuss budgets with Betty Scott,
and I can report further then.
-rpg-
∂28-Feb-88 1632 TEICH@Sushi.Stanford.EDU my master's courses
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 16:32:39 PST
Date: Sun 28 Feb 88 16:28:21-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: my master's courses
To: jmc@Sail.Stanford.EDU
Message-ID: <12378444841.28.TEICH@Sushi.Stanford.EDU>
There is a course listed this spring, CS408, titled "Expert Systems
Applications." Can this count for a Symbolics & Heuristics track elective??
david teich
-------
∂28-Feb-88 1746 weening@Gang-of-Four.Stanford.EDU GNU Emacs function
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 17:46:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03597; Sun, 28 Feb 88 17:46:50 pst
Date: Sun, 28 Feb 88 17:46:50 pst
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8802290146.AA03597@Gang-of-Four.Stanford.EDU>
To: jmc@Gang-of-Four.Stanford.EDU
Cc: rdz@Gang-of-Four.Stanford.EDU
Subject: GNU Emacs function
I've written a GNU Emacs function that is similar to the POINTER
command in E. Here it is:
(defun pointer-find-file (&optional arg)
"Search forward from point for a Unix filename and edit the named file.
With an argument N, find the Nth filename forward from point."
(interactive "p")
(or arg (setq arg 1))
(save-excursion
(while (> arg 0)
(setq arg (1- arg))
(re-search-forward "[~/][↑ \t\n]*[↑] \t\n!\"'(),./:;?]")))
(find-file (buffer-substring (match-beginning 0) (match-end 0))))
The regular expression matches filenames that start with "~" or "/",
followed by any number of characters except space, tab or newline,
and ending with any character except space, tab, newline, or most
delimiters that might be the punctuation at the end of a sentence.
It might have to be adjusted somewhat if it doesn't work as desired.
To use this function, put the definition in your .emacs file. If you
want to bind a short key sequence to it, e.g. "C-x p", add the form
(global-set-key "\C-xp" 'pointer-find-file)
"C-x p" is probably the most mnemonic sequence to use, but in GNU
Emacs it is already bound to the function narrow-to-page. So you may
want to choose a different key binding.
∂28-Feb-88 2322 CWeissman.BSPO@DOCKMASTER.ARPA S/W Report
Received: from DOCKMASTER.ARPA by SAIL.Stanford.EDU with TCP; 28 Feb 88 23:22:16 PST
Date: Mon, 29 Feb 88 02:12 EST
From: CWeissman@DOCKMASTER.ARPA
Subject: S/W Report
To: CWeissman@DOCKMASTER.ARPA
Message-ID: <880229071230.782957@DOCKMASTER.ARPA>
Resent-Date: 29 Feb 88 02:18 EST
Resent-From: CWeissman@DOCKMASTER.ARPA
Resent-To: Ouster@GINGER.BERKELEY.EDU,
MCHENRY%GUVAY.BITNET@CUNYVM.CUNY.EDU, HERN@RAND-UNIX.ARPA,
JMC@SAIL.STANFORD.EDU, BLUMENTHAL@A.ISI.EDU
Resent-Message-ID: <880229071824.376078@DOCKMASTER.ARPA>
John & Committee:
Your draft reads quite well and is a great first start. I am
sufficiently impressed to plagerize the format for the Network
subcommittee report I am writing. Here are my nits and bits.
Nits first:
par 2.3. My view is that s/w (software) components goes deeper to parts
of packages. You cite spreadsheets, word processors, et. al. I claim
deeper things from which such packages are created, like I/O drivers,
screen managers ( e.g. X-Windows), printer drivers, file access
methods, format converters (e.g., Lotus 123 to DIF), graphics functions,
screen/printer fonts, etc.
par 4. The US is importing a lot of software in Ada, Modula-2, Prolog,
OSI network protocols particularly the higher levels Transport Protocol,
TP (level 4), E-Mail, X.400 (level 7), and in between protocols. Also,
various 4th Generation Languages (e.g., LINK).
Bits Next:
par 6. We are now engaged in the debate over trades between Export
Restrictions and Export Competitiveness. I wrote my position earlier
that source code and maintenance support can be a very effective export
control vehicle, and find it absent from the writeup. Others agree as
per Bill McHenry's comments today. Also, as components (my level
granularity) improve, building complex systems will be more feasible by
less developed countries by "buy & tie" of such modules. How to
encourage that market without giving away the underlying intellectual
property is the challenge of competitiveness. What I see is a strong
desire of each national market to "customize" US products for its
consumers. In Japan, its the struggle to front end Konji characters;
Cyrilic in USSR, Arabic in much of the mid-east, etc. Licensing and on-
going maintenance are practical controls.
Possible breakthru may be a technique to "bind" a software module to a
specific cpu board. I know of current encryption R&D trying that
approach with "potted" cpu + cyrpto board such that cleartext never
appears outside the potted board. Then all code/data is always
encrypted in the computer except when executing. This also counters
binary dump copies. Further, the encryption key is an xor of the
manufacturer's distribution key, and the cpu key. The logistics of this
key management scheme is yet to be worked out. The issues are similar
tothe current debate on Digital Tape recorder scramblers to prevent
recording.
∂29-Feb-88 0328 ILAN@Score.Stanford.EDU re: Olympics
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 03:28:12 PST
Date: Mon 29 Feb 88 03:24:00-PST
From: Ilan Vardi <ILAN@Score.Stanford.EDU>
Subject: re: Olympics
To: su-etc@Score.Stanford.EDU
cc: jmc@Score.Stanford.EDU, ilan@Score.Stanford.EDU, jmc@Sail.Stanford.EDU
Message-ID: <12378564197.9.ILAN@Score.Stanford.EDU>
It's not just that the Olympics are flawed (by the way one man *was*
singlehandedly responsible for the Olympics stagnating for 40 years:
Avery Brundage), it's that they are generally shown as being an
example of human achievement at its highest and as being above
reproach.
None of the usual problems with the Olympics ever happen with
world championships in specific sports or even in combined championships
like track and field.
As an example of how the Olympics are above criticism is ABC's
abysmal coverage. Ignoring many of ABC's idiosyncrasies, its hiding
of truth and attempt to rewrite history is shameful. For example in
1976 Bill Johnson statement when asked what his medal meant to
him was ``millions.'' This was not mentioned in the TV coverage.
Instead ABC's medals ceremony template was used with Johnson the
unlikely hero. Jim McKay's spoke of how, from being arrested
for petty theft, those things were behind him and he had true
national pride. Jim McKay made a similar when the Italian anthem
played for playboy skier Alberto Tomba. He remarked that the glitter
was now gone and he was just another patriotic Italian. What does he know
about Italian patriotism? I think Jim McKay has seen too many (or
too few) Mussolini movies. I can imagine Jim fighting along with
Garribaldi for the unification of Italy.
As for rewriting history, I was amazed at how many times
Jean-Claude Killy's three gold medals were mentioned without one
remark about the fact that he won his medal in the Giant Slalom on
an extremely foggy course after Schrantz' winning time was disqualified
because one official claimed he had missed a gate, though Schrantz
swore he had skied down the course legally.
Actually I remember that a shot putter said in an interview that
the Olympics were ``just another track meet.'' He was severely
chastised by the USOC and the press.
-------
∂29-Feb-88 0900 RPG CPL
To: bscott@SCORE.Stanford.EDU
CC: JMC@SAIL.Stanford.EDU
I'm not sure what Scherlis told you, but he needs the proposal
today along with a cover letter from the dept stating that it
is applying for this new task. I was up most of the night preparing
the proposal and should have it done by 11 this morning.
He wants the cover letter faxed to him by early this afternoon:
(3) Cover letter needed asap. Signature is main element. The
proposal should be for a task on the SPAWAR contract.
The DARPA fax number is (202)694-5004. Be sure to call an hour later
to bve sure I've received it. Faxes often screw up.
Bill
-------
I will come by the dept between 11 and 11:30 with the proposal. Possibly
Nils or JMC could sign it.
-rpg-
∂29-Feb-88 1128 yao.pa@Xerox.COM course description
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 11:28:07 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 29 FEB 88 11:27:38 PST
Date: Mon, 29 Feb 88 11:29:13 PST
From: yao.pa@Xerox.COM
Subject: course description
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Cc: yao.pa@Xerox.COM
Message-ID: <880229-112738-1678@Xerox>
Topics in Computational Geometry
Discussion of selected topics in computational geometry. Emphasis on topics of
current research interest. Subjects that will be covered include range search
problems, geometric optimization problems, and finite-precision geometry.
Familiarity with analysis of algorithms is assumed.
∂29-Feb-88 1325 VAL book
I'm leaving the manuscript, in 4 parts, on your desk. Please tell me specifically
about the following items whether you're satisfied with them:
1. The new text at the beginning and at the end of my introduction (part 1,
p. 4 and pp. 10,11.
2. The Mr. Hug paper (part 1, p.68).
3. The two puzzles paper (part 3, p. 15).
As soon as you tell me the manuscript is ok, I'll send it to Ablex.
PS. I just noticed that I didn' initialize the section counter at the
beginning of several papers; that will be fixed.
∂29-Feb-88 1416 BSCOTT@Score.Stanford.EDU CPL Budget
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 14:16:44 PST
Date: Mon 29 Feb 88 14:10:56-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: CPL Budget
To: Scherlis@VAX.DARPA.MIL
cc: JMC@Sail.Stanford.EDU, RPG@Sail.Stanford.EDU, CLT@Sail.Stanford.EDU,
Littell@Score.Stanford.EDU, BScott@Score.Stanford.EDU
Message-ID: <12378681969.20.BSCOTT@Score.Stanford.EDU>
Since I am having Tab trouble on my terminal, Angie Littell will forward
the revised version of the CPL budget. I understand that Dick Gabriel is
sending the technical part.
We hope to have the formal proposal in Fed. Exp. mail on Thursday evening.
Let me know if you have questions or comments on the budget; otherwise, I
will plan to have an advance copy delivered to our Sponsored Projects Office
late today or early tomorrow morning so they can check it before receiving
the full proposal.
Betty
-------
∂29-Feb-88 1430 scherlis@vax.darpa.mil Re: CPL Budget
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 29 Feb 88 14:29:54 PST
Received: from sun45.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA00817; Mon, 29 Feb 88 17:30:50 EST
Posted-Date: Mon 29 Feb 88 17:24:37-EST
Received: by sun45.darpa.mil (5.54/5.51)
id AA00402; Mon, 29 Feb 88 17:24:38 EST
Date: Mon 29 Feb 88 17:24:37-EST
From: William L. Scherlis <SCHERLIS@vax.darpa.mil>
Subject: Re: CPL Budget
To: BSCOTT@score.stanford.edu
Cc: Scherlis@vax.darpa.mil, JMC@sail.stanford.edu, RPG@sail.stanford.edu,
CLT@sail.stanford.edu, Littell@score.stanford.edu
Message-Id: <573171877.0.SCHERLIS@VAX.DARPA.MIL>
In-Reply-To: <12378681969.20.BSCOTT@Score.Stanford.EDU>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
Betty --
I'm awaiting the budget, to arrive today. I'll be away until
4pm PST (PDT?), and will call you at that point if there are
any problems. Thanks,
Bill
-------
∂29-Feb-88 1437 littell@navajo.stanford.edu budget
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 29 Feb 88 14:37:20 PST
Received: by navajo.stanford.edu; Mon, 29 Feb 88 14:31:13 PST
Date: 29 Feb 1988 1431-PST (Monday)
From: Angelina Littell <littell@navajo.stanford.edu>
To: scherlis@vax.darpa.mil
Cc: JMC@sail.stanford.edu, RPG@sail.stanford.edu, CLT@sail.stanford.edu,
littell@navajo.stanford.edu, bscott@score.stanford.edu
Subject: budget
Budget
Common Prototyping Language
May 1, 1988 - October 31, 1989
Total
5-1-88/ 11-1-88/ 5-1-88/
10-31-88 10-31-89 10-31-89
Salaries
John McCarthy
Professor, Principal Investigator
3%, 5-1-88/10-31-89 1,500 3,150 4,650
Research Scientists
25%, 5-1-88/10-31-88
40%, 11-1-88/10-31-89
Richard P. Gabriel 9,375 30,000 39,375
Eric Benson 9,375 30,000 39,375
Harlan B. Sexton 9,375 30,000 39,375
To Be Named
20%, 5-1-88/10-31-89 7,500 15,000 22,500
___________________________________
Subtotal Salaries 37,125 108,150 145,275
Staff Benefits
26.2%, 9-1-87/8-31-88
27.1%, 9-1-88/8-31-89
27.8%, 9-1-89/8-31-90 10,020 29,438 39,458
Computing Costs 8,000 12,000 20,000
Travel
3 round trips, east coast
1 round trip, west coast 3,500 4,000 7,500
Expendable Materials
Phones, postage, supplies,
publications 1,500 4,000 5,500
________________________________
Subtotal, Direct Costs 60,145 157,588 217,733
Indirect Costs, 53% Off Campus
(Subject to Stanford University
Approval) 31,877 83,522 115,399
_________________________________
Total Budget 92,022 241,110 333,132
------- End of Forwarded Message
∂29-Feb-88 1455 VAL copyright fees
So far, Ellis Horwood is the only publisher who requested payment ($10 per
page; Ablex will pay). We still don't have replies from Edinburgh University
Press and from Her Majesty.
∂29-Feb-88 1506 Qlisp-mailer QDOTIMES, QDOLIST
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 15:05:56 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05828; Mon, 29 Feb 88 15:06:46 pst
Date: Mon, 29 Feb 88 15:06:46 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8802292306.AA05828@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Cc: pehoushek@Gang-of-Four.Stanford.EDU, rivin@Gang-of-Four.Stanford.EDU
Subject: QDOTIMES, QDOLIST
I have implemented a simple QDOTIMES, which uses the QEMPTY predicate
at each iteration to decide whether or not to spawn a process. This
QDOTIMES implementation IGNORES SOME HAIRY SYNTAX/SPAWN-PREDICATE
ISSUES. The syntax of this QDOTIMES is identical to DOTIMES. The
semantics of QDOTIMES is that the various iterations of the loop may
be evaluated in an arbitrary order. For example, I modified
Igor's matrix multiply routine using qdotimes instead of dotimes:
(DEFUN MULTIPLY (MAT1 MAT2 &OPTIONAL (OP1 #'+) (OP2 #'*))
(LET ((LENGTH1 (ARRAY-DIMENSION MAT1 0))
(WIDTH1 (ARRAY-DIMENSION MAT1 1))
(LENGTH2 (ARRAY-DIMENSION MAT2 0))
(WIDTH2 (ARRAY-DIMENSION MAT2 1)))
(LET ((RESULT (MAKE-ARRAY (LIST LENGTH1 WIDTH2))))
(qDOTIMES (I LENGTH1)
(qDOTIMES (J WIDTH2)
(SETF (AREF RESULT I J)
(INNER-PRODUCT MAT1 MAT2 WIDTH1 I J OP1 OP2))))
RESULT)))
The speed-ups are reasonably good. However, it took about 5 cpu
minutes to compile MULTIPLY?? Maybe "labels" is hard to compile.
QDOTIMES is implemented by changing the iteration to recusion, and
using #!.
-dan pehoushek
****
The code for implementing the QDOTIMES macro follows:
;;; A funtion call that takes an arbitrary number of arguments and returns nil.
;;; Used in the #! structure for synchronization.
(defun qsynch (&rest ignore)
(declare (ignore ignore))
nil)
;;; QDOTIMES, syntax identical to DOTIMES, with the natural parallel semantics.
;;; I changed iteration to recursion, and stuck in #!.
(defmacro qdotimes ((var howmany &optional result-form) &body do-form)
(let ((qdo-name (gensym "QDO"))
(form (cond ((= (length do-form) 1) (car do-form))
(t (cons 'progn do-form)))))
`(labels ((,qdo-name (,var)
(if (< ,var 0)
nil
#!(qsynch ,form (,qdo-name (1- ,var))))))
(,qdo-name (1- ,howmany))
,result-form)))
∂29-Feb-88 2315 SNOW@Sushi.Stanford.EDU AI course
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 23:15:19 PST
Date: Mon 29 Feb 88 23:11:02-PST
From: H. Roy Jones <SNOW@Sushi.Stanford.EDU>
Subject: AI course
To: jmc@Sail.Stanford.EDU
Message-ID: <12378780291.24.SNOW@Sushi.Stanford.EDU>
I'm teaching CS224, Introduction to AI, next quarter, and was hoping
you'd be willing to talk to me about what you think should be in that
class, as well as about the AI curriculum in general, and how 224 fits
into it.
If you have any time this week, that would be particularly helpful,
although any time over the next couple of weeks would be very appreciated.
Tuesdays and Thursdays are very good for me, but I'd try and make just
about any time.
Many thanks,
Roy Jones
-------
∂29-Feb-88 2323 SNOW@Sushi.Stanford.EDU re: AI course
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 23:23:18 PST
Date: Mon 29 Feb 88 23:19:03-PST
From: H. Roy Jones <SNOW@Sushi.Stanford.EDU>
Subject: re: AI course
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 29 Feb 88 23:21:00-PST
Message-ID: <12378781751.24.SNOW@Sushi.Stanford.EDU>
Sounds great. I'll see you then.
Roy
-------
∂01-Mar-88 1100 JMC
Cohn
∂01-Mar-88 1119 VAL McDermott on the frame problem
To: "@GELFON.[NET,VAL]"@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU,
shoham@SCORE.Stanford.EDU, ginsberg@SUSHI.STANFORD.EDU
For your information, here is Drew's response to my message about Gelfond's
method. I agree completely with the general discussion of the current state
of affairs at the end of his message.
∂01-Mar-88 0837 mcdermott-drew@YALE.ARPA Nonnormal defaults
Received: from CELRAY.CS.YALE.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 08:36:36 PST
Received: by CELRAY.CS.YALE.EDU; Tue, 1 Mar 88 11:20:17 EST
Date: Tue, 1 Mar 88 11:20:17 EST
From: Drew McDermott <mcdermott-drew@YALE.ARPA>
Full-Name: Drew McDermott
Message-Id: <8803011620.AA14523@CELRAY.CS.YALE.EDU>
Subject: Nonnormal defaults
To: val@sail.stanford.edu
Cc: hanks@YALE.ARPA, mcdermott@YALE.ARPA
Michael Gelfond has discovered a remarkably simple way to fix
the "Yale shooting" bug. In the formulation based on default logic,
you have the axiom
not ab(f,a,s) -> (T(f,s) -> T(f,result(a,s)))
and the default
: not ab(f,a,s) / not ab(f,a,s).
Gelfond showed that there will be a unique extension if, instead
of this, we use the non-normal default
: not ab(f,a,s) / T(f,s) -> T(f,result(a,s)).
How do you like it?
This idea was pointed out to us by Paul Morris of Intellicorp, except that
he put it in the form
T(f,s) : not ab(f,a,s) / T(f,result(a,s)).
(I think).
My first reaction was that this was a pretty good idea, except that it would
fail to exploit the expected power of nonmonotonicity. That is, suppose
we knew (F,A, and S0 are various constants):
T(F,S0)
not T(F,result(A,S0))
Then there will be no proof of ab(F,A,S0), and so the theory will simply
fail to have a fixed point. In other words, the conclusions are too
inviolable. There will be other cases (perhaps not expressible in the
classical situation calculus) in which two processes are "competing" over
the truth value of F. That is, one would make F true at time S1, and the
other would make it false at time S1. This is where you would *want* the
default logic to sprout multiple extensions, but the nonnormal version
would just fail to have any extensions.
If you tried to fix this problem by adding "backward" rules like
T(f,s) & not T(f,result(a,s)) -> ab(f,a,s),
then I think you get all the multiple extensions back whether you wanted
them or not.
A similar trick can be used in the framework of autoepistemic logic (simply
insert L after "not"), but it's apparently impossible to do anything like
this if we want to use circumscription.
Are you sure this would work in autoepistemic logic (in this case equivalent
to my modal logic)? Since the modal versions operate by inferring Mp from
inability to infer (not p), they seem intrinsically "normal." You can always
get to (not (M (not ab))) if the consequences of (not ab) are contradictory.
I am not sure what the bottom line is here. Steve and I did not originally
make it clear what roles nonmonotonicity was supposed to play. If its
sole purpose is getting concise frame axioms, so that projection can work
in the normal case, then nonnormal defaults do seem to solve our problem.
On the other hand, if we expect to write all sorts of axioms, default and
otherwise, and have the "right thing" just "fall out," then nonnormal
deaults seem too brittle. A similar sort of criticism can be made of
your "Formal Theories of Action" solution. It does fine if the normal
projections are correct, but if they fail (e.g., the victim isn't dead
after all), then it does funny things. Since it operates on action types
instead of tokens, it concludes that the relevant causalities *never* operate.
(I don't have the paper close at hand, so I am a little vague here. Also,
it's never been clear to me exactly what your system does in that case;
I'm guessing.) And as another example, consider Yoav's chronological
ignorance, which does better than all the rest in that it simply infers that
abnormalities must have occurred, except that it concludes
that the abnormalities occurred (e.g., the gun became unloaded) at the last
possible minute.
Is this carping? I don't know. On the one hand, the original McCarthy-Hayes
axiomatizations would simply become inconsistent if their projections led to
contradictions, so if all we're trying to do is tidy those axiomatizations
up, it seems unfair to demand that the tidier versions avoid the
inconsistencies. On the other hand, the McCarthy-Hayes axioms had lots of
problems as knowledge representations, one of which was their rigidity in
the face of "qualifications." Surely it is not too much to ask of a new
formalization that it handle simple versions of the qualification problem
as well as simple versions of the inertia problem.
In other words, I am asking for the moon. I want the logic to make
inferences backward and forward through time with equal ease, and I want
it to treat forward projection specially! With the benefit of hindsight,
it now appears really crazy to expect some general logic or its extension
to give this to us.
-- Drew
∂01-Mar-88 1344 ullman@navajo.stanford.edu PACO project
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:44:48 PST
Received: by navajo.stanford.edu; Tue, 1 Mar 88 13:40:31 PST
Date: Tue, 1 Mar 88 13:40:31 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: PACO project
To: dek@sail.stanford.edu, goldberg@score.stanford.edu,
guibas@score.stanford.edu, jmc@sail.stanford.edu,
mayr@navajo.stanford.edu, mitchell@score.stanford.edu,
pratt@score.stanford.edu, rwf@sail.stanford.edu, zm@sail.stanford.edu
Cc: amotz@navajo.stanford.edu, nilsson@score.stanford.edu,
peleg@navajo.stanford.edu
It appears that we shall be getting about $400K/year from DARPA,
along with $100K/year from ONR, to continue the parallel and distributed
computing project for a while. This money, together with some that
I can dredge up from the department as a sabbatical replacement for me,
should cover two postdoctoral people.
The following are possibilities:
1. Andy has suggested Serge Plotkin, who is graduating from MIT
sometime soon, and with whom he has worked in the area of parallel algorithms.
2. Joseph Naor has contacted me about a possible postdoc position.
He is presently working with Gary Miller at USC.
3. Uzi Vishkin has contacted everybody about hiring Uzi Vishkin.
He is more senior than the other two, and has a good track record.
The department declined to offer him a visiting position.
What do people think? Are there other possibilities of people who
would be interested in short-term appointments?
********************************************
While I'm thinking of it, the department has an opportunity to
receive a large grant of computer equipment from ATT; it would probably
consist of workstations and home computers capable of running unix,
although they have some bigger machines as well, including multiprocessors.
Apparently, no one outside of theory is interested in following up.
Would we like to get some of this equipment for theory students?
Could we support the upkeep?
---jeff
∂01-Mar-88 1431 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
THE MULTIPLE EXTENSION PROBLEM: WHERE ARE WE?
Matt Ginsberg (GINSBERG@SUSHI)
Stanford University
Friday, March 4, 3:15pm
MJH 301
All of the formal descriptions of nonmonotonic reasoning have difficulty
dealing with situations in which there are conflicts between the default
rules being used to analyze a particular domain. In most cases, little
is known about the problem of distinguishing among the multiple extensions
that arise as a result of these conflicts. In some instances, however --
inheritance hierarchies with exceptions, the qualification problem, and the
temporal projection problem -- it has been shown that there are good reasons
for preferring one extension over another. We describe a uniform framework
in which these ideas can be described and possibly extended.
∂01-Mar-88 1503 helen@psych.Stanford.EDU Dinner tonight?
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:03:37 PST
Received: by psych.Stanford.EDU (3.2/4.7); Tue, 1 Mar 88 15:03:01 PST
Date: Tue, 1 Mar 88 15:03:01 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Dinner tonight?
So, what do you say, are we still on for dinner tonight?
How about 6 p.m.? (I have subjects to whip along later...)
-helen
∂01-Mar-88 1532 helen@psych.Stanford.EDU re: Dinner tonight?
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:31:59 PST
Received: by psych.Stanford.EDU (3.2/4.7); Tue, 1 Mar 88 15:31:16 PST
Date: Tue, 1 Mar 88 15:31:16 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: Dinner tonight?
HI there,
Well actually 6 p.m. is pretty much it. And Thursday and Friday are
not possible. I'll have until 7:30 so it's not so bad. Meet in our
usual place at 6 p.m., then?
-h
∂01-Mar-88 1628 MPS National Geographic
Carol Douglas (from Natl Geo) is in the Bay Area interviewing people here,
SRI, etc. about the "Future of AI" and would like to see you tomorrow.
She has an appointment on campus at 3:30, but would be willing to shuffle
her schedule somewhat to see you. I told her it might be possible to see
you at 4:30 tomorrow. I hope this is alright with you. She will be
calling me when she arrives from Washington. Please confirm this appointment
with me. Thanks.
Pat
∂01-Mar-88 1632 MPS More
I forgot to tell you that this interview is about a book that National
Geographic is doing on Looking at the Future of AI.
Pat
∂01-Mar-88 2257 RFC Prancing Pony Bill
Prancing Pony bill of JMC John McCarthy 1 March 1988
Previous Balance 12.12
Monthly Interest at 1.0% 0.12
Current Charges 4.00 (bicycle lockers)
-------
TOTAL AMOUNT DUE 16.24
PAYMENT DELIVERY LOCATION: CSD Receptionist.
Make checks payable to: STANFORD UNIVERSITY.
Please deliver payments to the Computer Science Dept receptionist, Jacks Hall.
To ensure proper crediting, please include your PONY ACCOUNT NAME on your check.
Note: The recording of a payment takes up to three weeks after the payment is
made, but never beyond the next billing date. Please allow for this delay.
Bills are payable upon presentation. Interest of 1.0% per month will be
charged on balances remaining unpaid 25 days after bill date above.
An account with a credit balance earns interest of .33% per month,
based on the average daily balance.
You haven't paid your Pony bill since 11/87.
Accounts with balances remaining unpaid for more than 55 days are
considered delinquent and are subject to reduction of credit limit.
Please pay your bill and keep your account current.
∂02-Mar-88 0801 JMC
waltuch
∂02-Mar-88 0919 jbn@glacier.stanford.edu Re: two paths to AI
Received: from glacier.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 09:19:43 PST
Received: by glacier.stanford.edu; Wed, 2 Mar 88 09:21:36 PST
Date: Wed, 2 Mar 88 09:21:36 PST
From: John B. Nagle <jbn@glacier.stanford.edu>
Subject: Re: two paths to AI
To: JMC@sail.stanford.edu, jbn@glacier.stanford.edu
I take your point. A spectrum is a useful way to view this.
Sequencing the human genome seems premature, since we don't
know enough to digest that information as yet. But a smaller effort
devoted to understanding the nervous system of, say, an ant, might
be appropriate. Supposedly an ant has only a few hundred neurons.
Achieving a full understanding of a system of that size may be
within reach.
John Nagle
∂02-Mar-88 0949 GINSBERG@Sushi.Stanford.EDU no Formfeed this week
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 09:49:28 PST
Date: Wed 2 Mar 88 09:44:42-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: no Formfeed this week
To: Formfeed: ;
Message-ID: <12379157790.18.GINSBERG@Sushi.Stanford.EDU>
... since they are every other week and we had one last week.
Meanwhile, I am trying to set up a mailing list that is accessible
from outside of sushi. Meanwhile, here is the current mailing list.
Please let me know if there is anyone who should be added.
"Formfeed":-
!Devika Subramanian! subramanian@score,-
!Karen Myers! myers@sushi,-
!Matt Ginsberg! ginsberg@sushi,-
!John McCarthy! jmc@sail,-
!R Michael Young! young@sushi,-
!Haym Hirsh! hirsh@sumex,-
!Phil Stubblefield! phil@score,-
!Eunok Paek! paek@sushi,-
!Benjamin Grosof! grosof@score,-
!Vladimir Lifschitz! val@sail,-
!Don Geddis! geddis@sushi,-
!Doug Appelt! appelt@sri-warbucks,-
!Narinder Singh! singh@score,-
!Mike Genesereth! genesereth@score,-
!Jane Hsu! hsu@score,-
!Ramin Zabih! rdz@score,-
!Becky Thomas! bthomas@score,-
!Ron Loui! loui@csli,-
!Ken Fertig! fertig@score,-
!Andrew Baker! baker@sushi,-
!John Woodfill! woodfill@sushi,-
!Joseph Jacobs! jacobs@sushi,-
!David Smith! de2smith@score
Thanks! See you next week.
Matt
-------
∂02-Mar-88 1107 SHOHAM@Score.Stanford.EDU $
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 11:07:47 PST
Date: Wed 2 Mar 88 11:03:34-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: $
To: jmc@Sail.Stanford.EDU
Message-ID: <12379172147.35.SHOHAM@Score.Stanford.EDU>
John,
Has the Darpa money showed up? I need yo pay Lin.
Yoav
-------
∂02-Mar-88 1215 TEICH@Sushi.Stanford.EDU stopping by your office
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:15:38 PST
Date: Wed 2 Mar 88 12:10:13-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: stopping by your office
To: jmc@Sail.Stanford.EDU
Message-ID: <12379184282.32.TEICH@Sushi.Stanford.EDU>
I've stopped by a couple of times recently, and you weren't there.
What is the best time of the day to try?
david
-------
∂02-Mar-88 1403 GINSBERG@Sushi.Stanford.EDU Formfeed mailing list installed!
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 14:02:59 PST
Date: Wed 2 Mar 88 13:58:08-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: Formfeed mailing list installed!
To: feed@Sushi.Stanford.EDU
Message-ID: <12379203927.15.GINSBERG@Sushi.Stanford.EDU>
You can now send messages to the Formfeed mailing list by mailing
them to feed@sushi.
Matt
-------
∂02-Mar-88 1407 VAL Reply to McDermott's message
To: "@GELFON.[NET,VAL]"@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU,
shoham@Score.Stanford.EDU, ginsberg@SUSHI.STANFORD.EDU
∂02-Mar-88 1404 VAL re: Nonnormal defaults
To: mcdermott-drew@YALE.ARPA
CC: hanks@YALE.ARPA
[In reply to message from mcdermott-drew@YALE.ARPA sent Tue, 1 Mar 88 11:20:17 EST.]
A similar trick can be used in the framework of autoepistemic logic (simply
insert L after "not"), but it's apparently impossible to do anything like
this if we want to use circumscription.
Are you sure this would work in autoepistemic logic (in this case equivalent
to my modal logic)? Since the modal versions operate by inferring Mp from
inability to infer (not p), they seem intrinsically "normal."
The fact that it will work in autoepistemic logic follows from Konolige's
results on the relation between a.e. logic and default logic. These results
show that normal defaults correspond to the class of a.e. theories in which
every axiom containing L has the form
f -> Lf,
where f is a formula not containing L. (By the way, prerequisites correspond to
negative occurences of L, and this is the case when the correspondence between
the two systems becomes more complicated.)
This fact also follows from Gelfond's theorem announced in his AAAI-87 paper:
The result of inserting L after each negation in a stratified logic program is
an a.e. theory with a unique stable expansion. Actually, this is how Gelfond
first formulated his idea. Later he used Konolige's theorem to state it in
terms of default logic.
A similar sort of criticism can be made of
your "Formal Theories of Action" solution. It does fine if the normal
projections are correct, but if they fail (e.g., the victim isn't dead
after all), then it does funny things. Since it operates on action types
instead of tokens, it concludes that the relevant causalities *never* operate.
Yes, my axioms admit no exceptions to the laws of motion, and this isn't right
when we want to do explaining rather than prediction. I hope that can be fixed,
i.e., the axioms can be made a little bit weaker, so that they will be better at
explaining and still give the same result in prediction problems. But I don't
know yet how to do that, and if that turns out to be difficult, it will be
a serious blow.
Vladimir
∂02-Mar-88 1413 VAL book
Is there a chance you'll be able to give me your final instructions before
we go to TARK? If not, then maybe I should write to Ablex and tell them that
we haven't forgotten about the project. (The manuscript was supposed to be
there on Feb. 15.)
∂02-Mar-88 1507 ILAN@Score.Stanford.EDU Re: state of computer chess
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 15:07:35 PST
Date: Wed 2 Mar 88 15:03:08-PST
From: Ilan Vardi <ILAN@Score.Stanford.EDU>
Subject: Re: state of computer chess
To: JMC@Sail.Stanford.EDU
cc: ilan@Score.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 1 Mar 88 23:09:00-PST
Message-ID: <12379215759.30.ILAN@Score.Stanford.EDU>
I think that HITECH's rating has actually gone down slightly to
around 2340 (lucky for me since that's my rating). You can get
true information about HITECH's performance from Carl Ebeling
who is at the University of Washington (He wrote the program, though
Berliner allows the world to believe that he ``created it'') I have
his E-mail address and some mail he sent me a year ago.
I don't know too much about the state of micro computer ratings,
however I do have a (not too substatiated opinion) that the ratings
are highly inflated for the following reason: The programs are mostly
playing each other or else high rated mainframes like Hitech, Belle
etc... So the micro will play its first 20 games against Hitech,
Belle, Chess 5.x and do poorly but not terribly. This will give it a
1900 or so rating for the best micro. Then the micros play against
each other for all future time. Thus the micro rating word has a much
higher base rating than the human world (which has a 1300 base rating
I think), and the micros can get expert ratings. I haven't discussed
this with them, but it seems to explain these 2150 ratings you see in
ads.
By the way, there are canonical winning procedures against micros at
various levels. For example someone showed me the following
forced win against Chess Challenger at its easiest level (Computer=White)
1. E2-E4 E7-E5
2. N-F3 B-C5 ; ``forces'' white to take E-pawn
3. NxE5 BxF2 ; ``forces'' white to take Bishop
4. KxF2 Q-H4 ch ; white wll protect E-pawn (only in level 1)
5. K-E3 Q-G5 ch ; attacks king and knight
6. K-d4 C7-C5 ch ; wins back the knight with a winning game.
-------
∂02-Mar-88 1530 ilan@Gang-of-Four.Stanford.EDU HITECH's address
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 15:29:55 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA08610; Wed, 2 Mar 88 15:30:40 pst
Date: Wed, 2 Mar 88 15:30:40 pst
From: Ilan Vardi <ilan@Gang-of-Four.Stanford.EDU>
Message-Id: <8803022330.AA08610@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: HITECH's address
Cc: ilan@score
Ebeling's address is ebeling@vlsi.cs.washington.edu, I
also have a pretty funny example of Berliner's personality
(as seen in UNIX bboards)
-Ilan
∂02-Mar-88 2000 JMC
Take out phone book and maybe read something.
∂03-Mar-88 0054 ilan@Gang-of-Four.Stanford.EDU
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 00:54:42 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01085; Thu, 3 Mar 88 00:55:25 pst
Date: Thu, 3 Mar 88 00:55:25 pst
From: Ilan Vardi <ilan@Gang-of-Four.Stanford.EDU>
Message-Id: <8803030855.AA01085@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Chris Chase, a friend of Igor's and me, calls Hans Berliner
``Evil Hans,'' but I prefer ``Clever Hans.'' Here is an example
of him flaming away.
Article 757 of rec.games.chess:
Path: labrea!rutgers!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!berliner
From: berliner@K.GP.CS.CMU.EDU (Hans Berliner)
Newsgroups: rec.games.chess
Subject: Re: 4th round of Candidates
Message-ID: <765@PT.CS.CMU.EDU>
Date: 29 Jan 88 19:48:14 GMT
References: <3939@husc6.harvard.edu>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 11
Summary: Inconsistency in Report
Firstly, I want to also express my gratitude to David Frey for his
postings which are extremely valuable, especially so since Ken
Thompson is now in Australia. These "factual" reports stand out
well when compared to the wild opinions of certain regulars on this
net who never ever bother to state their qualifications to pontificate
on whatever subject they happen to have latched on to today.
Unfortunately, the retyping of the AP newsrelease must have produced an
error. In the round 3 report Vaganian leads Portisch 2-1; at the end
of 4 rounds he is behind 2.5-1.5 . Impossible!. David, could you please
be so kind.
From: berliner@K.GP.CS.CMU.EDU (Hans Berliner)
Newsgroups: rec.games.chess
Subject: Re: 4th round of Candidates
Message-ID: <771@PT.CS.CMU.EDU>
Date: 31 Jan 88 02:22:38 GMT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 44
> In article <765@PT.CS.CMU.EDU> berliner@K.GP.CS.CMU.EDU (Hans Berliner) writes:
> >Firstly, I want to also express my gratitude to David Fry for his
> >postings which are extremely valuable, especially so since Ken
> >Thompson is now in Australia. These "factual" reports stand out
> >well when compared to the wild opinions of certain regulars on this
> >net who never ever bother to state their qualifications to pontificate
> >on whatever subject they happen to have latched on to today.
>
> And here I thought opinions were to be encouraged as a way of getting more
> people involved in chess! Silly me. Perhaps Dr. Berliner would care to be more
> specific as to the pontifications which he finds objectionable. I
> personally find the second half of this pontification objectionable. I have
> personally found this newsgroup to be one of the most informative and well
> mannered that I have read on the net. I am often stimulated by the opinions
> whether or not I agree with them and whatever the qualifications of those that
> post.
>
> John Tomas
I come from a generation that was taught not to criticize something unless
you are prepared to do better. As such I find the batting around that Seirawan
took on this newsgroup rather objectionable. There are several strong
masters here, but even then ---. Maybe it is old-fashioned to speak of
one's betters with humility; but I rather believe not. In general, any
opinion about the quality of a chess move, game, series, or player is no
better than the chess ability of the proclaimer, and I would advocate that
for the first such posting by any particular proclaimer in any calendar
year, that he/she state such qualifications.
On another front, it is certainly useful for people to exchange info on
the merits of particular machines in an effort to guide potential
purchasers. However, an obvious attempt to steer people to one manufacturer
or to one outlet without any evidence that it is superior is rather crude
and makes the reader wonder what financial rewards the "salesman" is
expecting.
Finally, although there have been no questions of the type "when a knight
reaches the 8th rank can it still move backwards" recently, it really hurts
me to see this kind of nonsence. It seems that Hoyle's "Book of Games" is
there for people who really don't have a clue; and I for one would be
embarassed to show such a level of ignorance in public.
Venting one's opinions on the world is cheaper that going to a Psychiatrist
to get attention. However, it seems to me to violate the Golden Rule.
(My response titled: Er ist ein Berliner.)
Hans Berliner writes:
> Venting one's opinions on the world is cheaper that going to a
> Psychiatrist to get attention.
A great example of self-reference! I'll sure to include it in my
next class on recursion.
Article 767 of rec.games.chess:
Path: labrea!agate!ucbvax!ernie.Berkeley.EDU!tedrick
From: tedrick@ernie.Berkeley.EDU (Tom Tedrick)
Newsgroups: rec.games.chess
Subject: Re: Er ist ein Berliner
Message-ID: <22804@ucbvax.BERKELEY.EDU>
Date: 1 Feb 88 00:55:30 GMT
References: <16353@labrea.STANFORD.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: tedrick@ernie.Berkeley.EDU.UUCP (Tom Tedrick)
Organization: University of California, Berkeley
Lines: 12
->> Venting one's opinions on the world is cheaper that going to a
->> Psychiatrist to get attention.
->A great example of self-reference! I'll be sure to include it in my
->next class on recursion.
Can we please show some respect to the former World Champion?
We're very fortunate to have his input in this group.
If a World Champion isn't entitled to some respect, who is?
Dr. Berliner is also the creator of Hi-Tech, of course.
Article 768 of rec.games.chess:
Path: labrea!Gang-of-Four!ilan
From: ilan@Gang-of-Four.Stanford.EDU (Ilan Vardi)
Newsgroups: rec.games.chess
Subject: Re: Er ist ein Berliner
Message-ID: <16370@labrea.STANFORD.EDU>
Date: 1 Feb 88 05:15:18 GMT
References: <16353@labrea.STANFORD.EDU> <22804@ucbvax.BERKELEY.EDU>
Sender: news@labrea.STANFORD.EDU
Reply-To: ilan@Gang-of-Four.UUCP (Ilan Vardi)
Organization: Computer Science Department, Stanford University
Lines: 10
Correct me if I'm wrong, but it seems to me that HITECH was
designed by Carl Ebeling--at least that's the impression one
gets from reading his excellent book ALL THE RIGHT MOVES (which
was an ACM award winning dissertation). I found the book to be the
most elegant presentations of a computer chess program I have seen,
in part, I believe, because Ebeling is not an expert chess player and
so was able to avoid certain pitfalls of chess thinking.
For some mysterious reason, Ebeling's name is rarely if ever mentioned
in connection with HITECH.
(Berliner hasn't responded to this message which was sent in January,
though I sent mail to Ebeling asking him why he doesn't get credited
for HITECH. I'll forward that message if you like.)
∂03-Mar-88 0816 Qlisp-mailer Regarding a possible inconsistency in Catch/Throw.
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 08:16:05 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01576; Thu, 3 Mar 88 08:16:53 pst
Date: Thu, 3 Mar 88 08:16:53 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803031616.AA01576@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Cc: pehoushek@Gang-of-Four.Stanford.EDU
Subject: Regarding a possible inconsistency in Catch/Throw.
In defining the semantics of Catch and Throw, without considering
Futures for the moment, there is a possible inconsistency, highlighted by
uppercase (it is probably "just an implementation detail"):
"... may specify that child processes are to be killed and the throwing
process will then wait until all of them have died. The way these
processes are killed is by CAUSING THEM TO ISSUE a THROW that will
force any Unwind-Protect forms on their local stack to be evaluated...
Note: for Qlisp it is AN ERROR FOR ANY CLEANUP FORM in an
Unwind-Protect to attempt to throw to a tag outside of the
Unwind-Protect. "
To halt a subprocess, Force it to Throw; The inconsistency is in
FORCING a process to do a throw WHILE the process is executing
clean-up forms. To avoid inconsistency, A process must note that it
is executing clean-up forms, and Store up any "external Throws" caused
by processes other than its descendents.
...
P0
/
TAG0
qlet
/\
P1 P2
/ \
TAG1 UP
qlet \
/\ Clean-UP
P3 P4 TAG2
qlet
/\
P5 P6
When P3 throws to TAG1, P4 is sent a special Throw to Tag1 message is
sent to P4 via P1. This works fine.
When P3 throws to TAG0, P0 takes over. It is clear what to do with
P1, P3, and P4. However, P2 is in the middle of a clean-up. It
should store up the request from P0 to throw to TAG0 until it is done
with the clean-up forms.
What happens when P4 throws to a tag higher-up than TAG0? If a process
such as P2 has already received a message from its parent "to come
back home", then we do not need to send it another such message from
its grandparent "to come back home".
The gist of this discussion is that there needs to be a
PROCESS-TYPE-OF-EXECUTING-CODE field, with (at least) NORMAL, PROTECT,
and UNWIND as possible values. This adds more hair to UNWIND-PROTECT,
but it seems quite doable. There may be more subtle cases than the
one I have described. -dan
∂03-Mar-88 1041 Qlisp-mailer QDOTIMES, Matrix multiply
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 10:41:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA01818; Thu, 3 Mar 88 10:41:49 pst
Date: Thu, 3 Mar 88 10:41:49 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803031841.AA01818@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Cc: rivin@Gang-of-Four.Stanford.EDU, pehoushek@Gang-of-Four.Stanford.EDU
Subject: QDOTIMES, Matrix multiply
Igor suggested that the stack size in the old version of QDOTIMES
might grow too large. I agreed, and reimplemented QDOTIMES to look
like the doubly recursive calls used in QUICKSORT. It only took 4 and
one half minutes of CPU time to compile, and the stack size grows as
the Log of the number of iterations. Also, the speed-up over serial
DOTIMES is better with this version, avoiding the "linear" bottelneck.
For the N↑3 Matrix Multiply program, we get a speed up 1.6 on 2x2,
2.7 on 4x4, 3.3 on 8x8. The number of processes spawned is as
expected, and very consistent from run to run (using the N-scheduler
and QEMPTY). An interesting note is that, with matrices of
floating-point numbers, we level off at a speedup 3.5 and do not level
off (that is, we approach 4) with fixnums. Actually, the speed-up with
floating-point arrays peaks at 3.5. If the array size keeps
increasing, then the speed-up decreases, due to floating-point/page
resource allocation bottle-necks, I presume.
∂03-Mar-88 1248 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 12:48:29 PST
Date: Thu 3 Mar 88 12:41:14-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12379452073.12.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
March 4: Dr. Phokion G. Kolaitis (Stanford Univ.),
"The Expressive Power of Database Query Languages"
March 11: Prof. Zohar Manna (Stanford Univ.),
"Temporal Specification and Analysis of Concurrent Programs"
-------
∂03-Mar-88 1340 STAGER@Score.Stanford.EDU Re: industrial lectureships
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 13:40:06 PST
Date: Thu 3 Mar 88 13:35:52-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Re: industrial lectureships
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 3 Mar 88 12:43:00-PST
Office: CS-TAC 29, 723-6094
Message-ID: <12379462017.29.STAGER@Score.Stanford.EDU>
Thanks for the industrial lecturer listings. What about the general listing
under CS309? Last year we ran a blurb on each lecturer. Would you like to
do this again, or should I cut it down to something like this:
309. Industrial Lectureships in Computer Science---Each quarter the department
invites one outstanding computer scientist from local industry to give a course
in his/her specialty. Lecturers and topics change yearly, hence these courses
may be taken repeatedly.
And then list CS309A and CS309B course descriptions....
Please let me know if this is acceptable, or if you'd like to add some
background information on Frances Yao and Whitfield Diffie.
Thanks.
Claire
-------
∂03-Mar-88 1349 yuly@csv.rpi.edu opinion
Received: from csv.rpi.edu by SAIL.Stanford.EDU with TCP; 3 Mar 88 13:49:37 PST
Received: by csv.rpi.edu (5.54/1.14)
id AA07258; Thu, 3 Mar 88 16:53:05 EST
Date: Thu, 3 Mar 88 16:53:05 EST
From: yuly@csv.rpi.edu (Liang-Yin Yu)
Message-Id: <8803032153.AA07258@csv.rpi.edu>
To: jmc@sail.stanford.edu
Subject: opinion
Dear Prof. McCarthy:
I suppose you have already received the paper. If you have any
opinion about it, please feel free sending a message to me.
Thanks.
Liang-Yin Yu
∂03-Mar-88 1407 STAGER@Score.Stanford.EDU CS350
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:07:31 PST
Date: Thu 3 Mar 88 14:03:14-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: CS350
To: jmc@Sail.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12379466998.29.STAGER@Score.Stanford.EDU>
Will you be offering it next year?
Shall I run the same course description?
Change prerequisite to CS257 (from 257A)?
Thanks once again.
Claire
-------
∂03-Mar-88 1437 RDZ@Score.Stanford.EDU Quick question
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:37:38 PST
Date: Thu 3 Mar 88 14:33:25-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: Quick question
To: jmc@Sail.Stanford.EDU
Message-ID: <12379472495.52.RDZ@Score.Stanford.EDU>
Can I talk to you for about 5 minutes today? I'll be in my office
most of the afternoon and evening.
Ramin
-------
∂03-Mar-88 1633 STAGER@Score.Stanford.EDU re: industrial lectureships
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 16:33:38 PST
Date: Thu 3 Mar 88 16:29:26-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: re: industrial lectureships
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Thu 3 Mar 88 14:58:00-PST
Office: CS-TAC 29, 723-6094
Message-ID: <12379493615.54.STAGER@Score.Stanford.EDU>
Here's what I've come up with:
Frances Yao, a former member of the Stanford Computer Science faculty, is a
research scientist with Xerox Palo Alto Research Center where her current
field of interest is computational geometry; Whitfield Diffie is manager
of secure systems research for Bell-Northern Research, and inventor of
public key cryptography.
Claire
-------
∂03-Mar-88 1653 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
THE MULTIPLE EXTENSION PROBLEM: WHERE ARE WE?
Matt Ginsberg (GINSBERG@SUSHI)
Stanford University
Friday, March 4, 3:15pm
MJH 301
All of the formal descriptions of nonmonotonic reasoning have difficulty
dealing with situations in which there are conflicts between the default
rules being used to analyze a particular domain. In most cases, little
is known about the problem of distinguishing among the multiple extensions
that arise as a result of these conflicts. In some instances, however --
inheritance hierarchies with exceptions, the qualification problem, and the
temporal projection problem -- it has been shown that there are good reasons
for preferring one extension over another. We describe a uniform framework
in which these ideas can be described and possibly extended.
∂03-Mar-88 2152 Qlisp-mailer Regarding a possible inconsistency in Catch/Throw.
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 21:52:15 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA03420; Thu, 3 Mar 88 21:52:59 pst
Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 21:13:34 PST
Received: from bhopal.lucid.com by edsel id AA16937g; Thu, 3 Mar 88 16:04:53 PST
Received: by bhopal id AA13892g; Thu, 3 Mar 88 16:11:10 PST
Date: Thu, 3 Mar 88 16:11:10 PST
From: Ron Goldman <edsel!arg@labrea.Stanford.EDU>
Message-Id: <8803040011.AA13892@bhopal.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
In-Reply-To: Dan Pehoushek's message of Thu, 3 Mar 88 08:16:53 pst <8803031616.AA01576@Gang-of-Four.Stanford.EDU>
Subject: Regarding a possible inconsistency in Catch/Throw.
The point I was trying to make about cleanup forms in an UNWIND-PROTECT
doing a THROW, is that any external THROW that causes a cleanup form to
be evaluated takes precedence over any THROW out of the cleanup form.
For example does the code below return T or NIL?
(CATCH 'outer-tag
(CATCH 'inner-tag
(UNWIND-PROTECT
(THROW 'outer-tag T)
(THROW 'inner-tag NIL))))
In the current implementation it will return NIL, as the UNWIND-PROTECT
cleanup form preempts the initial THROW to 'outer-tag. For Qlisp I want
to switch things around so the THROW to 'outer-tag takes precedence. One
reason I prefer this approach is that a process can be killed by having
it do a THROW. I gather from JonL that the Common Lisp Cleanup committee
is currently debating the matter.
After thinking some more about the matter & talking it over with JonL, we
both seem to agree that rather than saying that a THROW in a cleanup form
has lower priority than an external THROW, what we should do is establish
a precedence relationship for THROW's such that the outermost tag has
precedence. Thus in the above example the THROW in the cleanup form to
'inner-tag would cause an error, since it would interfere with another THROW
to a tag with greater precedence that was already in progress. However,
in the following example, the THROW in the cleanup form would be ok:
(CATCH 'outer-tag
(CATCH 'inner-tag
(UNWIND-PROTECT
(THROW 'inner-tag T)
(THROW 'outer-tag NIL))))
and the evaluation of the above would return NIL. The following would also
be ok:
(CATCH 'outer-tag
(CATCH 'inner-tag
(UNWIND-PROTECT
(THROW 'inner-tag T)
(CATCH 'local-tag
(PROGN
(random stuff)
(THROW 'local-tag NIL))))))
since the THROW to 'local-tag in the cleanup form does not interfere with
the THROW to 'inner-tag which was in progress; the form would return T.
This will extend to multiple-processes in the (not necessarily) obvious
manner. Are things clearer now???
Ron
∂03-Mar-88 2248 @ELEPHANT-BUTTE.SCRC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Askey letter
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 Mar 88 22:48:31 PST
Received: from RUSSIAN.SPA.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 270796; Fri 4-Mar-88 01:48:29 EST
Received: from TSUNAMI.SPA.Symbolics.COM by RUSSIAN.SPA.Symbolics.COM via CHAOS with CHAOS-MAIL id 57384; Thu 3-Mar-88 22:48:29 PST
Date: Thu, 3 Mar 88 22:46 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: Askey letter
To: "DEK@SAIL.Stanford.EDU"@ELEPHANT-BUTTE.SCRC.Symbolics.COM
cc: "jmc@sail.stanford.edu"@ELEPHANT-BUTTE.SCRC.Symbolics.COM
In-Reply-To: The message of 29 Feb 88 10:44 PST from Don Knuth <DEK@SAIL.Stanford.EDU>
Message-ID: <880303224655.7.RWG@TSUNAMI.SPA.Symbolics.COM>
I got the copy today, tnx. Tell Phyllis Symbolics has moved to
Suite 120, 700 East El Camino Real
Mountain View, Cal. 94040.
The meeting Askey invites you to is the one I am worried about preparing for.
People are really expecting a show from me this time.
(Gripe: Stanford's weakness in computer graphics may be narrowing its choice of
neat grad student applicants, and cramping the creativity of the current batch.)
I am puzzled by Askey's claim of "what this (Dougall) identity really is". I see,
and am impressed by, the way those sums generalize the integrals, but he seems to
be saying that integrals have a greater reality than sums in his personal scheme
of things.
He doesn't mention Salamin's t (maybe we'd better call it r) generalization. Did
you show him that? Cursorily, it looks like the same limiting process will only
trivially generalize that Cauchy Beta integral (C). But since it seems to me
that a continuously scalable summation index is a profound generalization of Dougall,
and the limiting process hides this, then the integral is does not well serve as the
cognitive reference point. It's just a random limiting case. Maybe that's all he
means by "really is". Perhaps it's the most useful special case. This year.
It looks like the Macsyma group is going to be seriously late with the PC version,
and thus unable to use me soon. (And Mathematica may give them a real run for their
money.) Is the DARPA door still open?
∂03-Mar-88 2314 RDZ@Score.Stanford.EDU Meeting tomorrow
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 23:14:00 PST
Date: Thu 3 Mar 88 23:05:55-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: Meeting tomorrow
To: jmc@Sail.Stanford.EDU
cc: subraMANIAN@Score.Stanford.EDU
Message-ID: <12379565791.52.RDZ@Score.Stanford.EDU>
Devika and I were confused by Genesereth's description of the meeting as
a "AI faculty retreat", which it isn't. It's just the AI faculty who
happen to teach the required courses getting together. So, it's of no
use as far as fixing the AI Qual is concerned...
Ramin
-------
∂04-Mar-88 0057 cheriton@Pescadero.stanford.edu CSD Comp. The Second Coming
Received: from Pescadero (Pescadero.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 4 Mar 88 00:57:31 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA08014; Fri, 4 Mar 88 00:57:55 PST
Date: Fri, 4 Mar 88 00:57:55 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8803040857.AA08014@Pescadero>
To: comp@Pescadero.stanford.edu
Subject: CSD Comp. The Second Coming
Time to start thinking of the next Comp!
I propose that we aim for giving the exam in the week of May 16th-20th.
I think giving the 3 sections 16,18 and 20th at 7-10 pm would follow
the conventions followed to date in the order theory, systems, applications.
We would plan to meet the following week, say May 25th at noon to finalize pass/fail, etc.
I propose we aim to pretest 1st week of May so working backwards we should
have the exams drafted in April. However, the schedule depends on how
we want to run this. I propose as follows - I hate meetings.
1) We divide people into three groups corresponding to the three exams.
Each group picks a student member (or two?), develops their exam,
and selects pretesters, etc. and marks exam. Division of labor withi
a group is flexible but assigned by chairman if necessary.
2) I will propose the assignments to these groups and act as chairman of
each group (unless someone else is willing).
3) I will collect questions from each group and crunch into an exam for
first review by the respective groups, and then by others if willing.
I do not plan to meet before the exam except in response to demand.
This assumes each group being responsible about developing their exam
at a reasonable rate, standard and quality.
Please let me know if this approach is OK with you. Also, any inspired
input from the last exam experience would be appreciated.
Assuming my approach I propose:
a) Changes to the syllabus - too late for this exam. Now to exam for
the next round.
b) First draft of questions to me. April 6th.
c) Draft exams to each group: April 13th
d) Revisions to these exams due: April 20th
e) Revised exams to groups and committee as a whole: April 22nd
f) 2nd revision (inter-group adjustments) due: April 27th
g) Pretest: 1st week of May.
h) Marking of pretest and revisions by May 11th.
i) May 16/18/20 theory,systems and applications.
j) Pass/fail meeting: May 25th 12-2 pm.
k) goto Black Friday meeting with smile on face.
Please ack this message so I know I have reached everyone. Thanks.
David C.
∂04-Mar-88 0202 RDZ@Score.Stanford.EDU Industrial lectureships
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 02:01:51 PST
Date: Fri 4 Mar 88 01:57:40-PST
From: Ramin Zabih <RDZ@Score.Stanford.EDU>
Subject: Industrial lectureships
To: jmc@Sail.Stanford.EDU
Message-ID: <12379597058.52.RDZ@Score.Stanford.EDU>
Have you considered inviting one of the PARC people in AI? Someone like
Bobrow or Stefik might be interesting to have talk.
Ramin
-------
∂04-Mar-88 0340 TEICH@Sushi.Stanford.EDU re: stopping by your office
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 03:40:52 PST
Date: Fri 4 Mar 88 03:36:28-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: re: stopping by your office
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Wed 2 Mar 88 12:19:00-PST
Message-ID: <12379615044.10.TEICH@Sushi.Stanford.EDU>
Ok, I'll have to try later next week or next quarter. A family emergency
occured, and I will be leaving town tomorrow or saturday.
david
-------
∂04-Mar-88 0700 JMC
Morgenstern+Cohn
∂04-Mar-88 0700 JMC
pills
∂04-Mar-88 0812 Qlisp-mailer Juggling (Catch and Throw with Multiple Processes)
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 08:11:57 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04088; Fri, 4 Mar 88 08:12:45 pst
Date: Fri, 4 Mar 88 08:12:45 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803041612.AA04088@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Juggling (Catch and Throw with Multiple Processes)
My point was:
If a Process (P1) is executing a clean-up, Then, for the duration of
the clean-up execution, P1 is not Externally interruptable.
When P1 is doing a clean-up, and is asked (by its parent P0) to
Throw up, then P1 stores this request, to be dealt with up completion
of the clean-up execution. While it is doing a clean-up, P1 does NOT
propagate P0's Throw request. If, during the excution of P1's clean-up,
P1 makes a Throw even Higher than the one P0 requested, then P1 can
effectively ignore P0's Throw request.
In Ron's message, "Thus in the above example the THROW in the cleanup
form to 'inner-tag would cause an error, since it would interfere with
another THROW to a tag with greater precedence that was already in
progress." I think that throws to tags of lower precedence should be
ignored, because they are subsumed by a throw to a tag of greater
precedence, and NOT signal an error, or even be considered to be an
error. The "highest thrower" should always win; A little throw can
cause a cascade of higher and higher throws, ONLY when the higher
throws are in clean-up forms, which makes sense. If a clean-up form
makes a small throw outside of the clean-up, and the Process executing
the small throw knows about a higher throw, then it intercepts the
small throw, and does the HIGHEST KNOWN THROW.
-dan
∂04-Mar-88 0854 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU New Draft
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 08:54:15 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA05399; Fri, 4 Mar 88 08:51:18 PST
Date: Fri, 4 Mar 88 08:51:18 PST
From: ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU (John Ousterhout)
Message-Id: <8803041651.AA05399@nutmeg.Berkeley.EDU>
To: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.arpa,
jmc@sail.stanford.edu, mchenry@guvax.BITNET
Subject: New Draft
Cc: ouster@nutmeg.Berkeley.EDU
I've just completed a revision of the software subcommittee report
draft based on your comments. The full text of the new draft will
follow in a separate message. I've made major changes to the
protectability section, both in content and conclusion, based mostly
on Bill's comments. I've also made a number of small changes in
response to the various "nits and bits" I received. I wasn't able
to respond much to Tony's comments because I could relate them to
specific areas of the report or specific things to change (but if
you send me some specific text to add or delete I'll be happy to
do it). I think there's only one other comment that I didn't respond
to, which was Bill's comment about "X Window" being "X Windows". The
official name of the system is "The X Window System". It's sometimes
abbreviated to "X Windows" or just "X", but not "X Windows System".
I used the official name throughout the report.
I was supposed to get this draft to Sy by yesterday, but I've decided
to hold it until Monday, at which point I'll Federal-Express it to him.
So, if you have a chance to read over this draft there's still time for
me to make small changes (but probably only if you send me specific
text to add or delete). Major changes will have to wait until after
the committee meeting.
-John-
∂04-Mar-88 0857 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU Full Text of Draft
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 08:56:11 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA05404; Fri, 4 Mar 88 08:52:19 PST
Date: Fri, 4 Mar 88 08:52:19 PST
From: ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU (John Ousterhout)
Message-Id: <8803041652.AA05404@nutmeg.Berkeley.EDU>
To: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.arpa,
jmc@sail.stanford.edu, mchenry@guvax.BITNET
Subject: Full Text of Draft
Draft Report of the Software Subcommittee
NAS Committee to Study International Developments
in Computer Science and Technology
John Ousterhout
Tony Hearn
John McCarthy
Bill McHenry
Clark Weissman
1. Introduction and Overview
This document contains the initial findings of the
software subcommittee. It derives from a collection of
position statements submitted by the members of the subcom-
mittee. The body of the report consists of five sections.
The first section discusses the basic technology trends in
software as we see them, particularly the revolutionary
changes in the industry that have occurred because of the
arrival of a commodity market for software. The second sec-
tion describes four areas in which major breakthroughs seem
possible: concurrent programming, formal techniques, non-
procedural languages, and encryption techniques. The third
section gives our impression of the major national players:
the U.S. appears to be clearly dominant at this time, but
many other countries are focussing increasingly on the
software market. The fourth section discusses the software
situation in the Soviet Union; our opinion is that the
Soviets are far behind the Western industrial nations and
may have difficulties in catching up soon. The last section
discusses the issue of protectability: our conclusion is
that it is impossible to prevent the spread of software but
that Soviet access to Western software can be reduced
without impacting the competitiveness of the American
software industry.
2. Basic Technology and Market Trends
Our first task as a subcommittee was to survey the
state of the art in computer software and identify trends in
recent developments. The software industry has been revolu-
tionized by the arrival of personal computers and the accom-
panying explosion of software markets. This has changed the
nature of software development from monolithic systems
developed by large computer companies to small interoperat-
ing software components developed by small specialty firms.
It has also encouraged the development of standards,
resulted in vastly better development tools, and created a
- 1 -
Software Subcommittee Report March 4, 1988
greater focus on networking and communications.
This section also discusses briefly an unrelated topic,
namely the development of international software.
2.1. Commodity Market
The most significant recent development in computer
software has been the commoditization of the market caused
by the arrival of IBM and Apple personal computers and their
clones. Fifteen years ago there were essentially no com-
panies whose primary business was to develop commodity
software packages. Software was developed almost
exclusively in large organizations: large computer companies
developed software systems that they shipped in packages
with their hardware, and other large organizations (banks,
insurance companies, airlines, etc.) developed large appli-
cation packages for their own internal use. Software tended
to be shipped only in small quantities and was almost always
bundled with hardware. In many cases software was given
away or sold extremely cheaply: it served chiefly as an
inducement to buy the hardware on which it ran.
Today the situation has changed in two major ways.
First, the widespread use of personal computers has made it
possible for software packages to be distributed in enormous
quantities. It isn't uncommon for a popular software pack-
age today to have a million copies shipped, where only a few
years ago a thousand copies would have been considered
extraordinary. Second, there are now hundreds of smaller
companies developing, marketing, and profiting from
software. Most of them do not do any hardware development,
so they are dependent entirely on software for revenues. A
few years ago many people thought that it was not possible
to create a large profitable software company; today, com-
panies like Microsoft, Lotus, and Ashton-Tate show this
theory to be false. Even large computer manufacturers like
IBM and Hewlett-Packard have been restructuring their pric-
ing so that software can become a revenue source by itself
instead of a loss-leader to bolster hardware sales. As much
as 30% of IBM's revenue now comes from software (can anyone
verify this?).
2.2. Standard Interfaces
The commoditization of the software market has been
accompanied by the emergence of standard interfaces at many
levels. Fifteen years ago there was very little agreement
among vendors about anything: each computer manufacturer had
its own self-contained software systems with proprietary
interfaces and no compatibility with any other manufacturer.
Today there are dozens of widely-accepted standards covering
such things as instruction sets (such as the Intel 8086 and
Motorola 68000), file formats, graphics libraries (such as
- 2 -
Software Subcommittee Report March 4, 1988
Macintosh QuickDraw and the X Window System), operating sys-
tem interfaces (such as PC-DOS, Unix, and OS/2), page for-
matting languages (Postscript), and network protocols (such
as Ethernet, IP/TCP, and AppleTalk).
The motivation for adopting standard interfaces is that
they allow different companies to produce interoperable
hardware and software components. It no longer seems to be
possible for any one organization to produce all of the
software for a particular machine or environment. There
have been several major disappointments (such as Xerox's
Star and Apple's Lisa) where companies tried this approach.
The companies intended to produce virtually all of the
software for the systems in-house and intentionally made the
internal interfaces inaccessible or obscure. The result was
that very little software was developed for the machines and
the products were not successful. Most recent systems have
tended to be based on and to provide standard interfaces, so
that other manufacturers can develop additional software to
enhance the value of the system. The openness of the IBM PC
hardware and software, and the fact that those interfaces
became standards, are key reasons for the success of the PC.
2.3. Software Components
An overall effect of the trend towards commoditization
and standardization has been the development of a ``software
components'' business. Fifteen years ago software was typi-
cally distributed in large, monolithic, ``do-everything''
systems. Today software is more often marketed in small
packages. Spreadsheets, word processors, page layout pro-
grams, compilers, network communication, and many other
packages are all sold individually by different vendors.
Even package subcomponents, such as I/O drivers, screen
managers, file access methods, and format converters (e.g.,
Lotus 1-2-3 to DIF), are being marketed separately. The
large volume of potential shipments means that niche pro-
ducts can potentially generate large revenues. By designing
to existing standards, the new product can be used in exist-
ing systems with many other existing software packages, so
the new product's designers need not redevelop an entirely
new software environment. The result is that small organi-
zations can turn new ideas into exciting niche products very
quickly.
2.4. Development Tools
Tools for software development have been one of the
major beneficiaries of the software components business. It
is now possible to buy a modern language development system
with editor, compiler, linker, loader, symbolic debugger,
and run-time library for a hundred dollars. New development
tools are being produced at a dizzying pace. The result is
that software technology is fueling itself: new tools
- 3 -
Software Subcommittee Report March 4, 1988
shorten the development cycle, which results in more appli-
cation packages, including better tools which shorten the
development cycle even more, and so on.
2.5. Distributed Systems
Another recent trend in software technology is towards
distributed systems. The arrival of personal computers and
workstations made networking essential, since without it
each user would be isolated on his or her own machine.
Nowadays users expect machines to be able to work coopera-
tively in a variety of modes ranging from mail and file
transfer to shared network services for printing and filing.
Manufacturers without adequate networking software are find-
ing it increasingly difficult to compete.
2.6. International Software
A final technology trend is towards international
software (programs or systems that can be used with many
different national languages). This trend is still not
well-established, but appears slowly to be taking hold. For
example, there is it at least one major manufacturer working
on an international version of the Unix operating system.
Another example is Apple's HyperCard system, which promises
eventually to support different languages through automatic
translation mechanisms.
3. Breakthrough Possibilities
Our second task as a subcommittee was to consider where
there might be major breakthroughs in software over the next
ten or fifteen years. By ``breakthrough'' we mean an
improvement of an order of magnitude in some important
metric, such as performance, cost, development time, or
error rate. Compared to some of the hardware areas being
considered by the committee as a whole, software appears
much less amenable to major breakthroughs. We do not anti-
cipate any advances equivalent to the relentless exponential
increase in component density that has occurred for
integrated circuits. Gains in software are likely to come
slowly, if at all. Nonetheless, there appear to be at least
four areas in which breakthroughs are possible: concurrent
programming, formal techniques, non-procedural languages,
and encryption.
3.1. Concurrent Programming
One of the trends in the design of high-performance
computers is towards greater degrees of parallelism (the use
of several functional units or processors, all operating at
the same time, to speed up the solution of certain prob-
lems). Current supercomputers, like the Cray machines, have
- 4 -
Software Subcommittee Report March 4, 1988
small degrees of parallelism, either in the form of pipelin-
ing (e.g. in the Cray-1) or multiple processors (e.g. the
Cray-2). Although there will be continuing advances in the
speed of individual processors, much more potential perfor-
mance improvement is possible if large numbers of processors
can be applied concurrently to solve a problem. A few exam-
ples of highly-parallel machines are available today (like
those from Thinking Machines), and more examples are likely
to appear in the future.
The problem with highly parallel machines is how to
program them. Most existing software is written for a sin-
gle processor carrying out tasks sequentially. It is
extremely difficult to take a sequential program and subdi-
vide it so that different pieces may execute concurrently on
different processors. Some application areas appear well-
suited to parallelism, while others do not appear to map
conveniently onto concurrent machines. For parallel
machines to become widely used, new techniques must be
developed for programming them. The new techniques must be
accompanied by new development environments that allow effi-
cient concurrent programs to be produced quickly and easily.
Although this is an area of great importance, and one
in which a breakthrough would have major significance to the
computer field as a whole, it is not at all obvious that a
breakthrough will occur. Researchers have been working on
this problem for at least fifteen years without spectacular
results. Highly-concurrent programs have been developed for
a number of applications, but at great cost. The tools that
are currently available do not provide much assistance in
writing parallel programs. Overall, things don't seem a lot
better today than they did fifteen years ago.
On the other hand, there are probably more researchers
active in the field of concurrent programming now than ever
before, which will increase the likelihood of a break-
through. In addition, some recent developments, like the
Thinking Machines work, look promising, although it is still
too early to declare it a major breakthrough. A break-
through in the area of concurrent programming could result
in widespread use of machines with 10 to 100 times more pro-
cessing power than the machines most commonly available
today.
3.2. Formal Techniques
Another major focus of current research is in the
application of formal methods to software development.
Formal techniques can be applied in several ways. The most
rigorous approach is program verification: proof of func-
tional equivalence between a piece of code and a specifica-
tion of the code's intended behavior, or between a specifi-
cation and a set of requirements. Current technology allows
- 5 -
Software Subcommittee Report March 4, 1988
proofs between code and specification for up to 10,000 lines
of code, or between specification and requirements for up to
100,000 lines of specification, and the tools are emerging
from hand-craft to production quality. It is possible that
there may be major breakthroughs in this area by 1993-1995.
Even without proof of verification, formal techniques
can be applied to the development process, including, for
example, relational calculus, object-oriented design, well-
specified standards and interfaces, and strongly-typed
languages such as Ada, Modula, and Pascal. This trend can
potentially increase productivity by reducing the labor-
intensive post-design testing phase and the life-cycle
maintenance phase of software development. Semi-formal
techniques are already being applied to varying degrees in
many software development organizations.
This area is similar to concurrent programming in that
research efforts have been underway for almost 20 years,
with many disappointments and a few modest results to date.
It is possible that no major breakthrough will be forthcom-
ing. On the other hand, the technology appears to be gradu-
ally maturing; there are estimates that as much of 50% of
all software development will use formal techniques within
the next ten years. If verification techniques become
widely and successfully used in the software industry, they
could result in dramatic improvements in the reliability of
software and also in maintenance and testing costs.
3.3. Non-Procedural Languages
Some of the most exciting developments in software over
the last 10 years have consisted of new user interfaces
and/or ways of programming computers. Spreadsheet programs
are probably the best example of a successful new paradigm.
They represent a totally new way to manage and display
information in a computer, unlike anything that preceded
them. Spreadsheets also provide a novel programming
``language'' that is used to describe the relationships
between entries in the spreadsheet, so that a change in a
single entry can cause many other entries to be updated
automatically. This is a form of programming, but one that
is very different than a traditional programming language.
Another example of a novel programming paradigm is the
HyperCard system recently introduced by Apple. HyperCard
allows users to program the user interface by writing simple
procedures that describe the actions to take when buttons
are pushed or menu entries are selected. Once again, this
is a different way of programming than occurs in traditional
languages.
It is difficult to characterize the benefits that might
accrue from new programming paradigms, but it seems likely
- 6 -
Software Subcommittee Report March 4, 1988
that new paradigms will be invented in the next ten to fif-
teen years, and that these will revolutionize the way people
use computers in many application areas.
3.4. Encryption Services
User encryption services -- for integrity,
security/privacy, and authentication -- are just emerging
from government and university research laboratories. It is
possible that these will see widespread use in networks and
for software distribution over the next ten years. If a
breakthrough occurs, it could result in a substantial reduc-
tion in the penetrations and ``hacker attacks'' that have
occurred recently. Technology is not the limiting factor
here: the problem is to establish a coherent governmental
policy and to integrate the techniques into evolving net-
works and distribution channels. If encryption becomes
widely used, it could result in order-of-magnitude improve-
ments in the security of computer systems and permit comput-
ers to be used in more sensitive applications.
4. Major National Players
The subcommittee was unanimous in concluding that the
United States is the clear world leader in software. The
U.S. is the largest player, both in terms of production and
in terms of export, and is also the world leader in innova-
tion. The United States appears to be nearly self-
sufficient in software. The U.S. approach to software
development appears to be many years ahead of most other
countries: for example, the technology trend described in
Section 2 above, towards commoditization, standards, and
software components, seems to apply only to the U.S. Most
other nations still carry out software development in large
organizations, producing monolithic applications rather than
components, much like the U.S. did ten years ago.
On the other hand, there is an increasing interest in
software around the globe, with many countries explicitly
targeting the software area. The outstanding development
tools developed in the U.S. will certainly spread abroad,
which may allow other countries (particularly those with
cheap labor) to compete in software development. For exam-
ple, even now the U.S. is beginning to import software in a
few areas such as high-level languages (Ada, Modula-2, and
Prolog), higher-level network protocols such as X.400 (level
7), and 4th-generation languages such as LINK. The sub-
sections below survey the international scene to the best of
our knowledge. The information below is both incomplete and
potentially inaccurate, and consists of opinions collected
from the committee members and their acquaintances.
- 7 -
Software Subcommittee Report March 4, 1988
4.1. Japan
The Japanese produce a large amount of software of gen-
erally very high quality. However, it is mostly produced by
large software organizations within large companies such as
NTT and Hitachi. Software tends not to be sold in unbundled
form and is usually marketed only as part of larger
hardware-software systems. Much of the Japanese software
development effort appears to be in embedded application
software for such products as banking systems, nuclear power
plants, and computer-aided design tools.
The quality of Japanese software is generally con-
sidered to be very high, perhaps even better than U.S.
software. It appears to be common for Japanese software
developers to work very closely with their customers and to
guarantee the quality of the software they produce. Such
guarantees are unheard of in the U.S.
Because of their current organizational structure the
Japanese do not currently appear to be a major threat to
U.S. dominance. For example, neither the Japanese 5th Gen-
eration project nor the TRON project appears to have pro-
duced any major breakthroughs. On the other hand, the
Japanese seem to do well at almost everything they try; if
they decide to target software and to restructure themselves
to export commodity packages (which doesn't seem to have
happened yet), they could become a major player.
4.2. Europe
On the research side, the European community has tended
to focus more on theoretical and formal approaches than on
practical system-building, so they have not produced many
interesting software systems. However, the British appear
to be more engineering-oriented in their research than the
rest of Europe; for example, the Computer Laboratory at
Cambridge University has produced many interesting hardware
and software systems.
On the industrial side, most software development
appears still to be carried out in large teams in large com-
panies, for internal use. There appear to be very few
software startups, perhaps due to the lack of venture capi-
tal.
However, the software situation appears to be changing
in Europe. Countries like France, which used to be more
theoretically oriented, are becoming more practical (e.g.,
the Ada language design, which originated with a French
team). Some software exports are beginning to occur, such
as Prolog, Ada, and software development environments. In
countries like Italy and Hungary, more smaller software com-
panies are forming. For example, in Italy there is quite a
- 8 -
Software Subcommittee Report March 4, 1988
bit of internal development of applications packages; how-
ever, the packages are mostly used within the country and
are not often exported.
4.3. Other Countries
A number of other countries are attempting to become
major players in the software market. Both Malaysia and
Taiwan have targeted software as major national priorities,
and several U.S. firms have offloaded some of their software
development effort to Taiwan because of cheap labor rates.
Some software development is also starting to occur in India
and Israel.
4.4. Is the U.S. Inherently Superior?
There is some evidence that the U.S. has fundamental
cultural advantages for producing software. Innovative
software seems to spring from entrepreneurial environments
consisting of a small number of dedicated, creative, and
uncontrolled individuals. The ready availability of venture
capital, and our societal structure as a whole, seem to nur-
ture such developments. Most of the rest of the world
appears to be much more rigidly structured, with large
industrial organizations, little venture capital, and,
often, no incentives for entrepreneurs to try radically dif-
ferent approaches. Such an environment does not seem condu-
cive to making software breakthroughs. For example, the
Japanese have been much less successful in penetrating the
software markets than they have been in other areas, in
spite of a few highly visible projects like the 5th-
Generation project and TRON.
On the other hand, there is also evidence that the U.S.
lead in software will be threatened in the future. Software
development requires more than just creativity; once the
initial idea has been generated, an enormous amount of work
is required to produce a reliable product. Software is most
likely to be of high quality if it is developed in a struc-
tured environment by skilled craftsman who carefully parti-
tion the work and manage interfaces. Although the U.S. cul-
ture appears well-suited to generating creative ideas, our
culture tends not to emphasize structure and craftsmanship,
which are essential in producing a software product. Other
countries with better organizational structure and crafts-
manship (e.g., Japan) may find that they can take ideas from
the U.S. and produce better software products.
Furthermore, software is very labor-intensive. This
may make it possible for countries with cheap labor (includ-
ing most of Asia) to compete effectively in the software
markets. There is already some evidence of this, such as
the offloading of software production to Taiwan.
- 9 -
Software Subcommittee Report March 4, 1988
5. The Soviet Union
In the software area the Soviets have both strong cul-
tural advantages and strong cultural disadvantages. On the
positive side, the Soviet Union has a large pool of
extremely talented mathematicians. Given the mathematical
nature of software development, the Soviets could be formid-
able competitors if they had the right tools and the right
environment. If software development becomes more heavily
driven by the use of formal techniques as described in Sec-
tion 3.2, the Soviets could have an advantage. On the nega-
tive side, the Soviets suffer from two almost insurmountable
disadvantages. First, they do not have a large community of
unsophisticated computer users, which means there is little
motivation for developing new software packages. Second,
the Soviet culture, with its rigid central controls and lack
of incentives, presents exactly the opposite of the
entrepreneurial environment that seems to foster software
creativity. These two problems make it unlikely that any
major software innovations will occur.
If the Soviet Union were to make available the kind of
environment that would foster software development (large
numbers of personal computers in the hands of many individu-
als throughout society), it might result in major structural
changes to their society. For example, it would be diffi-
cult to make good use of personal computers without effec-
tive networking (as we have discovered in the U.S.). But
good networking would make it impossible for any central
organization to control communications and the flow of
information (as we have also discovered). This might not be
acceptable to the Soviets. On the other hand, developments
like those that have occurred in the U.S. computer industry
cannot occur without widespread use of computers. Our con-
clusion in Section 2 above was that the arrival of the PC in
million-unit quantities was the single greatest driving
force in recent U.S. software developments. Thus the
Soviets may be faced with a choice between a major societal
change and technological inferiority.
The current Soviet capabilities in several major
software areas are summarized below. In virtually every
area they lag substantially behind the rest of the world.
Many of their more developments consist of importing, emu-
lating, and slightly enhancing Western packages.
Operating Systems. The Soviets are at least 10-15
years behind the state-of-the-art. They have made sub-
stantial progress lately, but it all appears to consist
of imports or emulations of U.S. operating systems of
the 1970's. Many centers still do not even have mul-
tiprogramming, and current mainframe operating system
capabilities do not seem to have progressed signifi-
cantly past IBM's 1973 level.
- 10 -
Software Subcommittee Report March 4, 1988
Programming Languages. Fortran and PL/I are apparently
the most commonly-used languages, although the Soviets
have recently obtained an Ada compiler. There is
apparently a major effort to develop parallel-
processing languages. The development of higher-level
languages (fourth-generation languages, spreadsheets,
etc.) has been hindered by the lack of a large user
community.
Databases. There appears to be quite a bit of interest
in databases in the Soviet Union, and a number of sys-
tems are available (many of them very similar to
Western systems). Nontheless, in more sophisticated
systems, such as relational systems and PC-based data-
bases, the U.S. is definitely ahead and the gap is
widening.
Software Development Environments. Soviet developments
here appear to be very crude. For example, interactive
editors are unsophisticated and interactive debuggers
are not always even interactive, let alone symbolic.
Once again, the two problems are user community size
and central controls. Without a large unsophisticated
user community there is no incentive to develop power-
ful and easy-to-use tools. In a rigidly-controlled
environment, individuals and organizations are
encouraged to use existing tools rather than develop
new and better tools that deviate from national stan-
dards.
Artificial Intelligence. This has apparently been an
active area of research for many years, with most work
focussing on knowledge representation and natural
language processing. However, there appears to be no
coherent leadership or institutional support for AI;
much of the AI work appears to occur under the auspices
of some other discipline. Work in this area suffers
from lack of resources: for example, computer
resources are often at the level of the IBM PC or
worse, and there are few tools for building expert
systems.
6. Protectability
Our final task as a subcommittee was to consider the
issue of software protectability: can software be pro-
tected, and should it? This was the area of greatest dis-
cussion within the committee. On the one hand, we were con-
cerned that attempts to restrict software exports will be
ineffective and will damage U.S. competitiveness. On the
other hand, we think it may be possible to reduce the flow
of software to the Eastern block, and that this can be done
without restricting software exports to friendly nations.
- 11 -
Software Subcommittee Report March 4, 1988
This section reflects both views, interleaved in a discus-
sion of several issues related to protectability.
6.1. The Difficulty of Protecting Software
It is extremely difficult to restrict the flow of
software. It is too widely available, too easy to repli-
cate, and too easy to conceal. Diskettes not much larger
than a credit card can hold all the sources and binaries to
a major software package; there is no way to prevent them
from being carried and copied all over the world. One of
the best examples of the difficulty of protecting software
is the decision by several key software manufacturers
(including Lotus) not to copy-protect their disks. The pre-
vious copy-protect mechanisms were woefully inadequate and
tended to alienate customers. Instead, Lotus decided to
rely on low-pricing and honest customers, under the assump-
tion that most customers would prefer to pay a few dollars
than to make an illegal copy and risk trouble if discovered.
Because of its low replication cost, software is harder
to restrict than hardware. For example, given a single
diskette it is a relatively easy task to make a thousand
copies. Given a single personal computer, it is much more
difficult to make a thousand copies of the computer, partic-
ularly given the advanced manufacturing techniques and
high-tech components used today. Thus an approach that
slows the flow of hardware to an adversary might be effec-
tive because the adversary would not be able to accumulate a
large enough quantity of the hardware to make it widely
available. On the other hand, an approach that slows the
flow of software might not be effective unless it prevented
the adversary from getting even a single copy: given a sin-
gle copy the adversary could easily duplicate it enough to
meet all its needs.
In summary, it does not appear feasible to completely
cut off the flow of software to the Soviet Union, and merely
slowing the flow may not produce much benefit because the
Soviets can replicate it.
6.2. Denial of Source Code
On the other hand, we may be able to reduce the useful-
ness of stolen software by protecting the source code more
carefully than the executable binaries. Software is of lit-
tle use unless it can be adapted and supported. For exam-
ple, for scientific and engineering applications to be used
by the Soviets, they would likely have to be modified for
the Soviets' particular environment and problems. If these
applications were distributed in executable binary form only
and the source code were protected carefully, it would be
difficult for the Soviets to adapt the programs to their
needs. In addition, most programs require ongoing support
- 12 -
Software Subcommittee Report March 4, 1988
to fix bugs and add new features. If the source code and
documentation were protected then it would be difficult for
the Soviets to maintain the software; they would probably
have to continually re-acquire the programs from the West.
Unfortunately, it may be difficult to protect source
code. Most companies already attempt to protect their
sources, but internal security is usually lax. It would be
relatively easy for the Soviets to obtain sources to impor-
tant programs. Furthermore, the trend toward standards is
coming to include the distribution of sources as well as
binaries. For example, the X Window System is distributed
freely with sources. There are also thousands of copies of
the sources to the Unix operating system around the country,
although they are all licensed by AT&T. If source code
becomes widely distributed then it cannot be protected
against illegal export.
Another problem with source code protection is the
trend towards interchangeable library and subsystem com-
ponents. The components are often designed so that they can
be adapted for use in many different situations without
accessing the source code, merely by replugging or reconfi-
guring the components. To the extent that a component can
be reconfigured dynamically, an adversary can adapt the exe-
cutable binary of the component to his needs without access-
ing its source code.
Overall, though, we think it would be useful to
encourage companies not to distribute source code (this is
in their own commercial best interests anyway) and to be
especially strict in prohibiting source code exports to
unfriendly nations.
6.3. Denial of Hardware
Given the relative difficulty of replicating hardware
compared to software, the most effective way to prevent
Western programs from being used on Eastern-block countries
may be to deny the Eastern-block countries access to the
computers on which to run the software. The computers are
physically more bulky, hence easier to spot during illegal
export. Even here, though, continual miniaturization may
make export controls difficult. Furthermore, the Soviets
have shown themselves capable of building functional dupli-
cations of major machine architectures. This means that an
export control policy based only on denial of hardware will
just give the Soviets even stronger incentives to duplicate
our machines.
6.4. Competitiveness
Based on the difficulty of protecting software, one
might conclude that software should be freely licensed
- 13 -
Software Subcommittee Report March 4, 1988
abroad (even to Eastern block countries) so that U.S. com-
panies can profit from the exports. Those profits will go
back into the U.S. economy, resulting in further software
developments and an increasing edge: a positive spiral
feeding itself. There is some evidence that most conserva-
tive computing centers (e.g., all those in Eastern-block
countries) would prefer to purchase reasonably-priced
software than to risk being caught in a copyright or license
violation. If we make our software readily available to the
rest of the world, there will be less incentive for them to
develop their own software organizations; if U.S. software
is competitively priced, it will be harder for foreign
software organizations to generate revenues. On the other
hand, attempts to block software exports will not stop the
flow of information, but they will result in reduced exports
and profitability: a negative spiral feeding itself. If
U.S. software isn't reliably available abroad, it will
encourage the development and enhance the profitability of
foreign software organizations, which will eventually damage
the U.S. competitive position.
A countering view is that software should be freely
licensed to friendly countries but that there is no commer-
cial advantage to distributing to the Eastern block.
Eastern-block computer centers may prefer to buy software
directly, but they don't particularly have access to hard
currency in order to do so. Even if all of Gorbachev's
perestroika reforms are achieved, we are unlikely to see a
fungible currency from Eastern Europe anytime soon. It is
conceivable that a few computer centers will have the hard
currency to buy, but this is unlikely to be a very large
market.
The Soviets are likely to follow the same path they
have in the past: acquire the software from the West, make
some modifications as necessary (add a Cyrillic front-end,
for example), and distribute it for virtually nothing to
those who purchase hardware. Making the software easily
available to the Soviets simply means that this process will
be initiated sooner. Furthermore, removing all controls
will encourage entrepreneurial, ideal, small U.S. firms to
write applications directly for Soviet customers. Direct
legal sales to Soviet customers will result in maintenance
and training, which in itself constitutes considerable tech-
nology transfer.
6.5. Encryption
Our subcommittee was divided on whether encryption will
improve the protectability of software. One view is that
U.S. manufacturers must develop ``hacker-proof'' mechanisms
for preventing unauthorized use of software, and that
encryption techniques will lead to such mechanisms by the
mid-1990's. For example, it would be useful if software
- 14 -
Software Subcommittee Report March 4, 1988
could be linked to specific machines in a way that makes
vendor intervention necessary if the product is moved to
another machine. This would permit a vendor to export a
copy of a program to a foreign country while preventing the
recipient from redistributing to the Soviets (or to anyone
else, for that matter). Another approach currently being
explored consists of a ``potted'' CPU and encryption board
such that cleartext never appears outside the potted board.
Then all code and data is encrypted in the computer except
when executing. This also counters binary dump copies.
The opposing view is that any mechanism that permits
widespread distribution, no matter how controlled that dis-
tribution appears to be, cannot be protected against theft
by a dedicated opponent. For a package to be widely distri-
buted, the authority to grant access to that package must
also be widespread (e.g., among authorized distributors).
With such widespread authority all it takes is one dishonest
dealer who will make copies for use in Eastern-block coun-
tries. Given the ease of duplicating software, the primary
impediment to the Soviet Union may be the difficulty of
acquiring the first copy. Will encryption make this sub-
stantially more difficult?
6.6. Summary of Protectability
In spite of the difficulties of protecting software,
the subcommittee agreed that it was probably worth trying,
at least to the extent of prohibiting any export to
Eastern-block countries and encouraging the protection of
source code. Even if it is relatively easy for the Soviets
to acquire any given program, it would take an immense
effort to acquire sources or even binaries for the thousands
of interesting programs and application libraries that exist
today. The acquisition process would have to be repeated
continually as new programs become available old programs
are enhanced. Besides the expense of such an operation, it
would be difficult to keep it secret and it would be embar-
rassing to the Soviets if it were discovered. Once the
software arrives in the Soviet Union, it will have a dif-
ferent status than it would had it been purchased legally.
The use of the package will not be publicized and will prob-
ably be classified, the user groups may be restricted, and
all sorts of other controls put into place which erect
desirable barriers. Putting more links in the chain helps
to slow down the Soviets. The likely result is that the
Soviets would lag behind the West in their use of state-of-
the-art software. If there were no export controls, the
Soviets would probably acquire much more software much more
quickly, without providing much commercial advantage to U.S.
industry.
The subcommittee also agreed that we should do every-
thing possible to further the export of U.S. software to
- 15 -
Software Subcommittee Report March 4, 1988
friendly nations. Ideally, no licensing or bureaucratic
overhead at all should be necessary to export to friendly
nations. We should also support the development of tech-
niques (such as those based on encryption) that would
prevent recipients of software from being able to re-export
the software to the Eastern block.
7. Summary and Conclusion
The nature of software development in the U.S. has been
changed dramatically by the advent of personal computers.
Software is now developed in a decentralized fashion by hun-
dreds of companies, using standards and interoperable com-
ponents. The U.S. is currently the dominant international
player; virtually all other countries are still using the
centralized, monolithic approach to software development
that was common in the U.S. fifteen years ago. The Soviets
are particularly backward in the software area; without
major social changes (perestroika?) it appears unlikely that
they will be able to change this situation anytime soon.
Our conclusion is that the U.S. should not hinder
software exports to friendly nations, but should attempt to
restrict the flow to the Soviet Union. Techniques like
source-code protection and encryption, which would also help
to prevent unauthorized use of software by ``friendly''
nations, should be particularly encouraged. We should also
realize that absolute containment of software is infeasible
and that attempts to do so might well hinder the ability of
U.S. industry to compete in an increasingly international
marketplace.
- 16 -
∂04-Mar-88 0907 ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU One other note
Received: from nutmeg.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:07:08 PST
Received: by nutmeg.Berkeley.EDU (5.57/1.25)
id AA05428; Fri, 4 Mar 88 09:04:19 PST
Date: Fri, 4 Mar 88 09:04:19 PST
From: ouster%nutmeg.Berkeley.EDU@ginger.Berkeley.EDU (John Ousterhout)
Message-Id: <8803041704.AA05428@nutmeg.Berkeley.EDU>
To: blumenthal@a.isi.edu, cweissman@dockmaster.arpa, hearn@rand-unix.arpa,
jmc@sail.stanford.edu, mchenry@guvax.BITNET
Subject: One other note
I just remembered one other thing about the newest draft. A couple of
you mentioned the idea of dividing software into classes, some of which
would be more highly protected than others. I started to put something
about this into the report, then abandoned the effort, in part because
I couldn't figure out how to make it fit in, and in part because I'm
not convinced that it's a good idea. It seems to me that some kinds of
software are clearly sensitive (e.g., nuclear explosion simulators),
but that virtually all software is useful to the Soviets and will have
some military application. Isn't it just as important to keep them from
getting good operating systems and window systems as it is to keep them
from getting good explosion simulators?
Anyhow, if anyone feels strongly that there should be something about
this in the draft, send me some text and an indication of where to put
it.
-John-
∂04-Mar-88 1126 ARK Re: industrial lecturers
To: JMC@SAIL.Stanford.EDU, wiederhold@SUMEX-AIM.Stanford.EDU
CC: cbarsalou@SCORE.STANFORD.EDU, ARK@SAIL.Stanford.EDU
Since you have a slot free in the Spring, Witold Litwin will be available
to teach a course (he'll be visiting next year). I think Gio told you
about him. Gio or Caroline can get you a course description.
Arthur
∂04-Mar-88 1304 THOMASON@C.CS.CMU.EDU JPL article
Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 13:04:32 PST
Received: ID <THOMASON@C.CS.CMU.EDU.#Internet>; Fri 4 Mar 88 16:04:39-EST
Date: Fri 4 Mar 88 16:04:37-EST
From: Rich.Thomason@C.CS.CMU.EDU
Subject: JPL article
To: jmc@SAIL.STANFORD.EDU
cc: thomason@C.CS.CMU.EDU
Message-ID: <12379718471.25.THOMASON@C.CS.CMU.EDU>
John,
I'm starting to get some papers, so things are getting slightly
warmer. Any progress on that article? I may see you at TARK II, and
if so will pester in person.
--Rich
-------
∂04-Mar-88 1347 VAL CS326 - please reply as soon as possible
The curriculum committee met this morning and came up with a plan to
reorganize 323/326. Essentially, it eliminates overlaps and extends 326
to 2 quarters, as you wanted:
32x. Nonmonotonic reasoning -- (Same as Philosophy 32x.) Formalisms for
representing nonmonotonic reasoning and their applications to Artificial
Intelligence. Nonmonotonic aspects of commonsense knowledge and reasoning.
Default logic, autoepistemic logic and circumscription. Computational
nonmonotonic reasoning. Applications of nonmonotonic formalisms to
inheritance systems, to reasoning about action, and to logic programming.
32y. Knowledge and change [Yoav is working on the description.]
In order to have this included in the next year catalogue, I need your
approval by 3pm today. Please reply as soon as possible.
∂04-Mar-88 1502 Qlisp-mailer new-qlisp
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 15:02:52 PST
Received: from labrea.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06176; Fri, 4 Mar 88 15:03:39 pst
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 14:24:34 PST
Received: from kolyma.lucid.com by edsel id AA22558g; Fri, 4 Mar 88 14:51:58 PST
Received: by kolyma id AA20682g; Fri, 4 Mar 88 15:01:57 PST
Date: Fri, 4 Mar 88 15:01:57 PST
From: Carol Sexton <edsel!carol@labrea.Stanford.EDU>
Message-Id: <8803042301.AA20682@kolyma.lucid.com>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: new-qlisp
I've just installed a new new-qlisp in which all
known bignum problems are fixed.
Carol
∂04-Mar-88 1509 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: industrial lecturers
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 15:09:09 PST
Date: Fri, 4 Mar 88 15:08:32 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: industrial lecturers
To: ARK@SAIL.Stanford.EDU
cc: JMC@SAIL.Stanford.EDU, cbarsalou@SCORE.STANFORD.EDU,
"*PS:<WIEDERHOLD>LITWIN.INRIA-NSF-PROPOSAL-88.1"@SUMEX-AIM.Stanford.EDU
In-Reply-To: Message from "Arthur Keller <ARK@SAIL.Stanford.EDU>" of Fri, 4 Mar 88 11:26:00 PST
Message-ID: <12379741032.38.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
I have all the material and course proposal by Litwin here.
Should I e-mail it to you?
His course could useful complement research we are planning.
Gio
-------
∂04-Mar-88 1518 WALDINGER@WARBUCKS.AI.SRI.COM Re: industrial lecturers
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 15:18:01 PST
Date: Fri 4 Mar 88 15:15:51-PST
From: Richard Waldinger <WALDINGER@WARBUCKS.AI.SRI.COM>
Subject: Re: industrial lecturers
To: JMC@SAIL.STANFORD.EDU
Message-ID: <573520551.0.WALDINGER@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(215)+TOPSLIB(126)+PONY(198)@WARBUCKS.AI.SRI.COM>
should i ask mark stickel if he would be interested?
richard
-------
∂04-Mar-88 1638 ARK CS309 course description
∂04-Mar-88 1632 CBARSALOU@Score.Stanford.EDU CS309 course description
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 16:32:32 PST
Date: Fri 4 Mar 88 16:28:12-PST
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
Subject: CS309 course description
To: stager@Score.Stanford.EDU
cc: wieDERHOLD@Score.Stanford.EDU, jcm@Sail.Stanford.EDU, ark@Sail.Stanford.EDU
Message-ID: <12379755534.10.CBARSALOU@Score.Stanford.EDU>
Claire,
Here it is eventually ! Good luck to you.
Caroline
Gio : Filename: CS309.description on cbarsalou@score
CS309
Dr Witold Litwin is a senior researcher at the French INRIA Institute,
and has contributed to the design and management of their distributed
database systems. He also has developed novel hashing techniques for
file access.
MANAGEMENT OF MULTIPLE DATABASES
Modern database systems need capabilities for management of data in
multiple autonomous databases, usually distributed. The course will
present techniques for implementation of such capabilities. It will
start with a brief description of the classical top-down approach to a
distributed database design. It will then move to new methodologies
founded on the notions of bottom-up integration, local autonomy,
interoperability, federated databases and of a multidatabase system.
The methodologies will be compared and systemized with respect to
concepts, reference models and terminology. The course will then
focus on techniques for heterogeneous and autonomous data management:
new capabilities for database languages for cooperative data
definition and manipulation, multidatabase views, static and dynamic
homogenization of data values and models, query decomposition,
transaction processing... It will in particular examine main
prototypes, (System R*, MULTIBASE, MRDSM, MESSIDOR, MERMAID, DDTS,
CALIDA, ...). Furthermore, we will present related developments which
will influence the design of future systems, especially in Europe: Use
of high-speed networks and personal workstations, Open System
Architecture, European public videotex systems, especially the French
Teletel system. Finally, the course will present and compare
capabilities for the management of multiple databases of the
commercial systems that recently appeared, or should have
corresponding releases available soon: SYBASE, INGRES (STAR), ORACLE
V5, EMPRESS V2....
-------
∂04-Mar-88 1650 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
SOME COMPUTATIONAL ASPECTS OF CIRCUMSCRIPTION
Phokion G. Kolaitis (KOLAITIS@NAVAJO)
Stanford University
Friday, March 11, 3:15pm
MJH 301
We explore the effects of circumscribing predicates in first-order formulae
from a computational standpoint. First, extending work of V. Lifschitz, we
show that the circumscription of any existential first-order formula is
equivalent to a first-order formula. After this, we investigate the
circumscription of Horn clauses. We show that a finite set of (universally
quantified) Horn clauses has a first-order circumscription if and only if
the associated logic program is bounded. It is known that boundedness is
an undecidable property of logic programs. Thus, it is an undecidable
problem to tell whether universal first-order formulae have a first-order
circumscription. Finally, we show that there are first-order formulae
whose circumscription has a coNP-complete model checking problem. This is
joint work with C.H. Papadimitriou.
∂04-Mar-88 1726 SINGH@Sierra.Stanford.EDU Faculty support sought for position on Immigration Laws
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 17:26:11 PST
Date: Fri 4 Mar 88 17:25:51-PST
From: Harinder Singh <SINGH@Sierra.Stanford.EDU>
Subject: Faculty support sought for position on Immigration Laws
To: su-etc@Sierra.Stanford.EDU
cc: INS-interest-group: ;
Message-ID: <12379766028.35.SINGH@Sierra.Stanford.EDU>
A broader base of faculty support could make a
tremendous difference to the growing list of signatories
in support of the position paper on Reform of Legal
Immigration Laws.
For those who find themselves in agreement with
the thrust of the proposed changes, I have an action
request:
At the very minimum, please forward the proposal
to as many of your colleagues nationwide as you have
electronic mail addresses for. Please ask them to post
it on any bboards where it is appropriate, and write
me (or the Senators directly) if they agree with the
contents.
--->>> It would be fabulous if any of the faculty
members agreeing with the proposal at Stanford could
help enlist the support of University Presidents and
Provosts, starting with the President and Provost of
Stanford. What I have in mind is that once the proposal
gets the support of people like Presidents Donald
Kennedy and Derek Bok (of Harvard), its chances of
success will be greatly enhanced.
EVERYONE who reads this and happens to agree
with the proposal for reforming Legal Immigration Laws
is hereby asked to help the process along by forwarding
it to their friends across the country by email, and
requesting consideration of it, followed by action
where appropriate.
The response in the 24 hours that the proposal
has been out has been unanimously in support. I believe
that judicious use of technology (ie networks) could
yield a wild-fire of support in the next week, providing
plenty of opportunity to have a positive impact on a
difficult situation.
Thanks again,
Sincerely,
Inder
Bcc list: Please do not feel in the least pressured to do
anything if the proposal does not appeal to you.
A reply is not essential. Thanks, Inder
INS-Interest-Group: Your assistance in furthering
the message, right from your terminals, would be invaluable.
Please send it along to as many friends on the net as
possible, with a request for further propagation as
deemed appropriate. Please suggest forwarding to local
media contacts (campus and city newspapers, radio stations etc)
wherever possible. Thanks!
-------
∂04-Mar-88 1732 WIEDERHOLD@SUMEX-AIM.Stanford.EDU CS309
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 17:32:15 PST
Date: Fri, 4 Mar 88 17:31:46 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: CS309
To: stager@SCORE.STANFORD.EDU
cc: jmc@SAIL.Stanford.EDU, ark@SAIL.Stanford.EDU
Message-ID: <12379767105.38.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Well revise the description.
Is it the Fall or the Spring?
Gio
-------
∂05-Mar-88 0759 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU a comment--what do you think?
Received: from ucscd.UCSC.EDU ([128.114.129.2]) by SAIL.Stanford.EDU with TCP; 5 Mar 88 07:59:29 PST
Received: by ucscd.UCSC.EDU (5.57/1.1)
id AA14104; Sat, 5 Mar 88 08:00:47 PST
Date: Sat, 5 Mar 88 08:00:47 PST
From: beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU (20012000)
Message-Id: <8803051600.AA14104@ucscd.UCSC.EDU>
To: jmc@sail.stanford.edu
Subject: a comment--what do you think?
Cc: val@sail.stanford.edu
Dear John,
This is a short follow-up on my comment at your recent lecture, which you
may remember: This formalism enables one to see clearly what the problem
really is. Namely, when we have reasoned to a contradiction, and every
conclusion has its "pedigree" present in the system, we still need to
throw out some past conclusions, and even with the pedigrees all present
WE NEED SOME RULES to determine which ones to throw out.
When using circumscription, one supplies these rules on an ad hoc basis,
by specifying which predicates will be circumscribed, which ones will be
varied, and with what priorities. One always does this in just the way
which will lead to the conclusion that one knew in advance one wanted to
reach. And similar difficulties are encountered by all the other approaches
to formalization of non-monotonic reasoning.
Nakashima's recent draft suggests the rule "more specific information
takes precedence over more general information". I think that is a good
example of the kind of rule I have in mind. But to make that precise
we need a definition of "more general"; one which, for example, would
determine that the information that Fred's mother is British is more
specific than the information that people encountered in America are
typically American. These (unspecified) rules should be used to determine
the order of priorities and which predicates will vary in circumscription.
In a satisfactory formalization of commonsense reasoning, the SYSTEM,
not the user, must determine these things.
I would like to know your opinion of this analysis.
Michael Beeson
≠
∂05-Mar-88 1435 weening@Gang-of-Four.Stanford.EDU
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Mar 88 14:35:44 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05494; Sat, 5 Mar 88 14:36:27 pst
Date: Sat, 5 Mar 88 14:36:27 pst
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8803052236.AA05494@Gang-of-Four.Stanford.EDU>
To: jmc@sail
(defun pointer-find-file (&optional arg)
"Search forward from point for a Unix filename and edit the named file.
With an argument N, find the Nth filename forward from point."
(interactive "p")
(save-excursion
(re-search-forward "[~/][↑ \t\n]*[↑] \t\n!\"'(),./:;?]" nil nil arg))
(let ((filename (buffer-substring (match-beginning 0) (match-end 0))))
(if (file-exists-p filename)
(find-file filename)
(error "File %s does not exist!" filename))))
∂05-Mar-88 1448 JSW
user%host.bitnet@forsythe
∂06-Mar-88 1859 Qlisp-mailer no meeting this week
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 18:58:56 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00357; Sun, 6 Mar 88 18:59:12 pst
Date: Sun, 6 Mar 88 18:59:12 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8803070259.AA00357@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: no meeting this week
As ARG is leaving on vacation, and RPG is going to Washington.
∂06-Mar-88 2301 ARK Revised CS309 course description
To: stager@SCORE.STANFORD.EDU
CC: CBARSALOU@SCORE.STANFORD.EDU, wieDERHOLD@SCORE.STANFORD.EDU,
JMC@SAIL.Stanford.EDU, ARK@SAIL.Stanford.EDU
Here is the revised course description for Litwin for the Spring.
Arthur
309C. Federated Databases---Study of multiple autonomous databases,
usually distributed, including implementation. Top-down distributed
database design, bottom-up integration, local autonomy, interoperability,
federated databases, and of a multidatabase system. Heterogeneous and
autonomous data management: new capabilities for database languages for
cooperative data definition and manipulation, multidatabase views, static
and dynamic homogenization of data values and models, query decomposition,
transaction processing. Survey of research prototypes. Future directions
including use of high-speed networks and personal workstations, Open
System Architecture, European public videotex systems, especially the
French Teletel system.
3 units, Spring (Litwin)
Dr. Witold Litwin is a senior researcher at the French INRIA Institute,
and has contributed to the design and management of their distributed
database systems. He also has developed novel hashing techniques for
file access.
∂07-Mar-88 0855 TALEEN@Score.Stanford.EDU Re: Nagorno-Karabakh
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 08:55:35 PST
Date: Mon 7 Mar 88 08:51:19-PST
From: Taleen Nazarian <TALEEN@Score.Stanford.EDU>
Subject: Re: Nagorno-Karabakh
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 6 Mar 88 10:00:00-PST
Message-ID: <12380458792.26.TALEEN@Score.Stanford.EDU>
I never really knew about it, but my husband knew that the area which
is in dispute had been a part of Armenia for a long time. Although
the majority of the residents of Karabakh are Armenian, they'd been considered
a minority because that region technically belongs to Azerbaijan. The
Azerbaijanis, being Turks, had been bothering the Armenians for a long time.
Right before the news of the demonstrations hit the press, it was reported
that 70 Armenians were killed in that region. Recently, there have been
reports of more fatalities, as well as rapings and robberies (see Saturday's
Chronicle -- headline story).
I believe the reason for the demonstrations is that Armenians from the
Azerbaijan region are seeking refuge in Yerevan and are asking for assistance.
They are now being joined by other Armenians in demanding that the region
that belonged to Armenia (I think up to 70 years ago, it was a part of
Armenia. I'm not sure about this) be returned to (Soviet) Armenia. After all,
they do make up 90 percent of the population there. Armenians here are
supporting them in this request. As for your question about whether the
Armenians are demonstrating against the Soviet government, I can't say for
sure. Right now, the government is their only hope of keeping them alive.
They have no where else to turn. I guess they are hoping that the region
be part of Soviet Armenia, with a chance that some time in the future, Armenia
can once again be a free republic. The Soviets respect Christian populations
more than they respect Arab populations, so the Armenians have a pretty good
chance of getting Gorbachev to support them. I guess the Armenians feel
that succumbing to massacres for centuries (marked by the major one at
the turn of this century) should finally come to an end. They're sick of
being the underdog. They feel that this is finally the time to stand up for
what they believe in. Even if it means asking for Soviet help (they really
have no choice), they want to go after what they feel is their right.
I have a copy of Saturday's Chronicle, if you'd like to read the article.
I can bring it in tomorrow.
Taleen
-------
∂07-Mar-88 1052 REIS@Sierra.Stanford.EDU High Noon Lecture
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:52:28 PST
Date: Mon 7 Mar 88 10:52:30-PST
From: Rick Reis <REIS@Sierra.Stanford.EDU>
Subject: High Noon Lecture
To: jmc@Sail.Stanford.EDU
cc: reis@Sierra.Stanford.EDU
Message-ID: <12380480853.29.REIS@Sierra.Stanford.EDU>
John:
Greetings. The April 15th date for your high noon talking is
slowly approaching andI wanted to check in with you and ask if
in the next week or so I could get a title from you and a very
brief (one paraqgraph) description of the talk I could use for
publicity purposes.
I also wanted to let you know that if you need any assistance in
preparing overheads, slides, etc. that are needed for a general
audience please let me know- we have a small budget for such
matters.
Thanks
Rick
-------
∂08-Mar-88 0553 @ELEPHANT-BUTTE.SCRC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Prof Moriarty an unindicted co-collaborator?
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 Mar 88 05:53:16 PST
Received: from RUSSIAN.SPA.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271855; Tue 8-Mar-88 08:52:52 EST
Received: from TSUNAMI.SPA.Symbolics.COM by RUSSIAN.SPA.Symbolics.COM via CHAOS with CHAOS-MAIL id 57582; Tue 8-Mar-88 05:52:53 PST
Date: Tue, 8 Mar 88 05:52 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: Prof Moriarty an unindicted co-collaborator?
To: "dek@sail.stanford.edu"@ELEPHANT-BUTTE.SCRC.Symbolics.COM
cc: "jmc@sail.stanford.edu"@ELEPHANT-BUTTE.SCRC.Symbolics.COM,
rwg@RUSSIAN.SPA.Symbolics.COM
Message-ID: <880308055240.9.RWG@TSUNAMI.SPA.Symbolics.COM>
Research problem and answer 1.23 (periodic rational linear recurrences)
are really a mess. First of all, the {n+k}s should be {n-k}s. Second,
if the denom can be constant (i.e. only b0≠0), then the recurrence is
linear and you can have any period you like. If you rule that out,
then there is still X_n = omega/X_{n-17}, e.g.. Yet at the same time,
rational linearity rules out too much, e.g. X_n ← 1/X_n, or the frequency
doubled Todd sequence X_n = X_{n-1} X{n-3} / X{n-2}, (period 4) or the
frequency doubled Lyness Q_n = (Q_{n-2}+1)/(Q_{n-1} Q_{n-2} - 1), (period 5).
Probably the right closure is X_n = L_1(1,X_{n-1},...) / L_2(1,...), where
the Ls are linear in each X_i, but permit crossterms. More succinctly
0=L(1,X_n,X_{n-1},...).
Yet even with the artificial restriction against crossterms, the answer
overlooks X_n = -1/(1+X_{n-1}), (period 3).
But this was just an excuse to ask you:
Who is perpetrating this "Moriarty's identity" hoax? I am aware of the
Conan-Doyle reference. But I've got this Russian book (which I can't
read, except maybe with a dictionary) by Yegorichev, which makes makes
several references to "tozhdyestvamy Moriarty", given as some moderately
puzzling binomial sums. (They look like Gauss's thm, except
with a half-integer shift of the summation index.)
JMC, you didn't, did you?
∂08-Mar-88 1204 tom@polya.stanford.edu SAIL's operating expense/budget
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Mar 88 12:02:36 PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA20308; Tue, 8 Mar 88 12:02:46 PST
Date: Tue, 8 Mar 88 12:02:46 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803082002.AA20308@polya.stanford.edu>
To: Nilsson@tenaya.stanford.edu, wheaton@athena.stanford.edu
Cc: jmc@sail.stanford.edu, ball@navajo.stanford.edu
Subject: SAIL's operating expense/budget
Arthur Keller just came into my office and wanted to see our CSDCF budget
as far as SAIL was concerned, under the directive of John and Nils.
I would think that if this is indeed the case where John or Nils wants
Arthur to see the budget that you would have told either JimB. or
myself. We are not in the pratice of giving a copy of the budget
to whomever wants it since it does contain confidentiality.
How would you like me to proceed? Would it be better for Jim or I to explain
to John or yourself the budget.
thanks
tom
∂08-Mar-88 1327 wheaton@athena.stanford.edu SAIL's operating expense/budget
Received: from athena.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:27:23 PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA00325; Tue, 8 Mar 88 13:27:43 PST
Date: Tue, 8 Mar 88 13:27:43 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803082127.AA00325@athena.stanford.edu>
To: tom@polya.stanford.edu
Cc: Nilsson@tenaya.stanford.edu, jmc@sail.stanford.edu,
ball@navajo.stanford.edu
In-Reply-To: Tom Dienstbier's message of Tue, 8 Mar 88 12:02:46 PST <8803082002.AA20308@polya.stanford.edu>
Subject: SAIL's operating expense/budget
Tom,
I don't understand why ARK wanted the budget. You're correct, if we
had wanted him to see it or work with it we should have notified Jim.
Obviously, I don't know what instructions Arthur got from Nils or
John, and I'm speaking only for myself, but he should show "good
cause" for getting into that sort of thing. Off hand, I can't think
of any.
GW
∂08-Mar-88 1333 wheaton@athena.stanford.edu SAIL's operating expense/budget
Received: from athena.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:33:37 PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA00343; Tue, 8 Mar 88 13:33:58 PST
Date: Tue, 8 Mar 88 13:33:58 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803082133.AA00343@athena.stanford.edu>
To: JMC@SAIL.stanford.edu
Cc: tom@POLYA.stanford.edu, Nilsson@TENAYA.stanford.edu,
ball@NAVAJO.stanford.edu, ARK@SAIL.stanford.edu
In-Reply-To: John McCarthy's message of 08 Mar 88 1259 PST <8803082059.AA08956@Tenaya.stanford.edu>
Subject: SAIL's operating expense/budget
Thanks, John, the explanation helps.
George
∂08-Mar-88 1346 SHOHAM@Score.Stanford.EDU no ride
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:46:06 PST
Date: Tue 8 Mar 88 13:40:42-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: no ride
To: jmc@Sail.Stanford.EDU
Message-ID: <12380773618.22.SHOHAM@Score.Stanford.EDU>
John, In case you do not see my note, I'm afraid I can't offer you
a ride back to Asilomar. It would have been nice. Sorry. I'll see
you there. Yoav
-------
∂08-Mar-88 1542 CLT mail
To: "@JMC.DIS[1,CLT]"@SAIL.Stanford.EDU
Betty Scott says someone has been charging mailing services to 2-DMA762
(the old DARPA formal reasoning contract). This contract has expired.
Please do not use it any more.
∂08-Mar-88 1605 BA.GLK%RLG.BITNET@forsythe.stanford.edu LISP, SAIL QUESTIONS
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Mar 88 16:04:26 PST
Received: by lindy.stanford.edu; Tue, 8 Mar 88 16:05:54 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Mar 88 16:03:36 PST
Date: Tue, 8 Mar 88 16:03:36 PST
From: Gary Kent <BA.GLK%RLG.BITNET@forsythe.stanford.edu>
To: JMC@sail.stanford.edu
Subject: LISP, SAIL QUESTIONS
I am a programmer in Production Services at the Research Libraries
Group on campus. We have the Amdahl 5890-300E (128 Meg memory) at
Forsythe.
1. Would you mind if I were to audit one of your classes in
LISP?
2. Do you know where I can find out information about SAIL?
Thanks,
Gary Kent, ba.glk@rlg, 329-3552.
To: JMC@SAIL
∂08-Mar-88 1609 nilsson@Tenaya.stanford.edu SAIL's operating expense/budget
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Mar 88 16:09:29 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA09139; Tue, 8 Mar 88 16:09:19 PST
Date: Tue, 8 Mar 88 16:09:19 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803090009.AA09139@Tenaya.stanford.edu>
To: tom@polya.stanford.edu
Cc: wheaton@athena.stanford.edu, jmc@sail.stanford.edu,
ball@navajo.stanford.edu
In-Reply-To: Tom Dienstbier's message of Tue, 8 Mar 88 12:02:46 PST <8803082002.AA20308@polya.stanford.edu>
Subject: SAIL's operating expense/budget
I might have told Arthur that I had no objections to his giving us
some advice about computing or something. I did not intend to imply
that he had my backing for asking you for confidential information.
You should politely tell him it's confidential, to give you a list of
the items he would like to know about, then you and Jim Ball and George
can look at the list to see if it's a good idea to give him the info.
I'm generally against extra bureaucracy, but Arthur has to learn sometime that
there is a right way and a wrong way to go about things. -Nils
∂08-Mar-88 1817 ARK re: SAIL's operating expense/budget
To: nilsson@TENAYA.STANFORD.EDU, tom@POLYA.Stanford.EDU
CC: wheaton@ATHENA.STANFORD.EDU, ball@NAVAJO.STANFORD.EDU,
ARK@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU
I asked Tom for a "one-page summary of what went into the charges for
SAIL". I was told this contained confidential information. So I asked
for a sanitized version that doesn't contain confidential information.
That's what PIs used to be able to get from Ralph Gorin when CSD-CF was
first set up.
Here's one from Ralph's old files (unprotected):
8 Oct 81
SAIL Score Xerox Sun Common Total
Coates Crispin Roberts .8 Todd .5 Gorin .5
Frost Schnurle Tech .25 Black .5 Bosack
Hayes Tech .25 Tom D .5 Gotelli .5
Mock .5 David B Tien-H .5
Tech .5 Stu Hrly SRA
Stu Hrly Stu Hrly
Salaries 118,448 72,828 21,328 82,957 98,034 393,595
Benefits 25,111 15,440 4,522 17,587 20,783 83,443
-------- ------- ------ ------- ------- -------
Total Sal 143,559 88,268 25,850 100,544 118,817 477,038
Travel 10,868 10,868
Maintenance 57,500 32,000 20,000 109,500
Expendables 57,600 39,600 10,000 23,600 130,800
-------- ------- ------ ------- ------- -------
Total Direct 201,159 185,368 57,850 110,544 173,285 728,206
Depreciation 40,000 154,000 54,000 64,000 312,000
New Depr. 7,670 11,196 25,327 44,193
-------- ------- ------ ------- ------- -------
System totals 248,829 350,564 111,850 110,544 262,612 1,084,399
alloc common
& development
costs: 169,040 155,606 48,510 (110,544) (262,612)
-------- ------- ------ ------- ------- -------
Chargable 417,869 506,170 160,360 1,084,399
totals
With all due respect and apologies,
I don't understand why it isn't possible to get one just like this
for 87-88.
Thanks.
Arthur
∂09-Mar-88 0711 ball@navajo.stanford.edu re: SAIL's operating expense/budget
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Mar 88 07:11:19 PST
Received: by navajo.stanford.edu; Wed, 9 Mar 88 07:07:18 PST
Date: Wed, 9 Mar 88 07:07:18 PST
From: James E. Ball <ball@navajo.stanford.edu>
Subject: re: SAIL's operating expense/budget
To: JMC@sail.stanford.edu, nilsson@tenaya.stanford.edu, tom@polya.stanford.edu
Cc: ARK@sail.stanford.edu, ball@navajo.stanford.edu,
wheaton@athena.stanford.edu
We don't like the idea of giving out the detailed budget, which contains all
salary information without a direct order from our management. It seems to me
that salary information is just not handed out without some formal written
request from either George or Nils and then only in a confidential manner. I
have always been taught and directed to handle salary information as confidential.
As far as I am concerned the salary information is the main reason for not
giving out the budget to everyone who asks for it.
With regard to CSD-CF being a useless dinosaur I would like to point out that there
are a number of people who spend a great deal of time, much of it without any
recognition, keeping the dinosaur alive. Perhaps we should be taken to the dinosaur
graveyard and put out of our misery along with the systems.
Jim
∂09-Mar-88 0721 tom@polya.stanford.edu SAIL's operating expense/budget
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Mar 88 07:21:26 PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA06809; Wed, 9 Mar 88 07:21:48 PST
Date: Wed, 9 Mar 88 07:21:48 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803091521.AA06809@polya.stanford.edu>
To: ARK@SAIL.Stanford.EDU
Cc: nilsson@TENAYA.STANFORD.EDU, wheaton@ATHENA.STANFORD.EDU,
ball@NAVAJO.STANFORD.EDU, ARK@SAIL.Stanford.EDU, JMC@SAIL.Stanford.EDU
In-Reply-To: Arthur Keller's message of 08 Mar 88 1817 PST <8803090218.AA29867@polya.stanford.edu>
Subject: SAIL's operating expense/budget
This reason that we can't just whip out somethinkg like this is because
we don't have anything that is this simple. Interesting numbers though,
SAIL's cost is less now than the 81 budget even with the raising salaries
which is basically what SAIL's cost are.
I will come up with a copy of our budget that should be what you want to see.
tom
∂09-Mar-88 1017 GINSBERG@Sushi.Stanford.EDU Formfeed tomorrow
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 10:17:13 PST
Date: Wed 9 Mar 88 10:12:02-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: Formfeed tomorrow
To: feed@Sushi.Stanford.EDU
Message-ID: <12380997774.26.GINSBERG@Sushi.Stanford.EDU>
Don't forget that formfeed meets tomorrow! Needless to say, there is
no agenda.
Matt
-------
∂09-Mar-88 1230 RDZ@Score.Stanford.EDU Hertz Luncheon March 25
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 12:30:23 PST
Date: Wed, 9 Mar 1988 12:25 PST
Message-ID: <RDZ.12381022104.BABYL@SCORE.STANFORD.EDU>
From: RDZ@Score.Stanford.EDU
To: jmc@Sail.Stanford.EDU
Cc: jsw@Sail.Stanford.EDU
Subject: Hertz Luncheon March 25
There's a lunch for fellows on Friday March 25. We're all supposed to
invite our advisors (I guess that means you get invited twice). They
would like us to RSVP by March 15.
Ramin
∂09-Mar-88 1434 tom@polya.stanford.edu sail costs
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Mar 88 14:34:49 PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA14058; Wed, 9 Mar 88 14:35:12 PST
Date: Wed, 9 Mar 88 14:35:12 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803092235.AA14058@polya.stanford.edu>
To: ark@sail.stanford.edu
Cc: JMC@sail.stanford.edu, ball@navajo.stanford.edu,
wheaton@athena.stanford.edu
Subject: sail costs
I have left a part of our spread sheet that has the direct costs that are
associated to SAIL in your mailbox.
tom
∂09-Mar-88 1501 GINSBERG@Sushi.Stanford.EDU formfeed room change: March 10 ONLY
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 15:00:56 PST
Date: Wed 9 Mar 88 14:55:55-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: formfeed room change: March 10 ONLY
To: feed@Sushi.Stanford.EDU
Message-ID: <12381049454.38.GINSBERG@Sushi.Stanford.EDU>
Because of a conflict, we'll be meeting in MJH 301 on March 10
instead of the usual 252.
Matt
-------
∂10-Mar-88 0906 MPS ttac meeting
Chris from Jet Propulsion (818 354-4431) called to ask you if
you plan to be there on the 14th. Also, your accommodations
have been changed to the Holiday Inn, 303 Cordova Street, Pasadena
(818) 449-4000. They are right around the corner of the place
where you were suppose to stay. I imagine she has made the
arrangements for Monday night.
Pat
∂10-Mar-88 0935 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU triangles
Received: from ucscd.UCSC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 09:35:15 PST
Received: by ucscd.UCSC.EDU (5.57/1.1)
id AA09204; Thu, 10 Mar 88 09:36:31 PST
Date: Thu, 10 Mar 88 09:36:31 PST
From: beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU (20012000)
Message-Id: <8803101736.AA09204@ucscd.UCSC.EDU>
To: jmc@sail.stanford.edu
Subject: triangles
A half-hour inspection of Borevich and Shafarevich reveals zero relevant
theorems. Hasse Minkowski apparently does not apply to systems of forms
but only to single forms; and if you combine our system to a single form
it is of degree four. (The system is: k(a↑2+b↑2+c↑2)=u↑2+v↑2+w↑2,
au+bv+cw=0). Degree four forms in general can be solvable mod p↑n for
every p and n and still not be solvable in integers.}i~rq¬X+&|λ_+A$:t∨πbUε|ZE←ε?sM>xn[>∨v'bM4λe1
(If this is garbled at your end it's because my wife picked up the phone
upstairs). I begin to suspect that for k=7 the equations have no solution.
However, you wanted to know about n-dimensional space. If n is 5 or more,
you can take a=1, b=c=d=e=0, then take u=0 and write k as a sum of four
squares u,v,w,x; so in dimension 5 or more the condition I stated is
necessary and sufficient (the dot-product formula still defines angles
in n-space).
∂10-Mar-88 1024 HENZINGER@Sushi.Stanford.EDU Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 10:24:28 PST
Date: Thu 10 Mar 88 10:18:23-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
Message-ID: <12381261075.19.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
March 11: Prof. Zohar Manna (Stanford Univ.),
"Temporal Specification and Analysis of Concurrent Programs"
(final talk this quarter).
-------
∂10-Mar-88 1120 Qlisp-mailer Amount of idle time with cutoff d in Fibonacci
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 11:20:09 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04670; Thu, 10 Mar 88 11:20:19 pst
Date: Thu, 10 Mar 88 11:20:19 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803101920.AA04670@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: Amount of idle time with cutoff d in Fibonacci
The question is, assuming 0 scheduling overhead, and a fixed spawn/depth
cutoff d, how much idle processor time will there be, when calculating
Fib(N)?
With 4 processors and a cutoff depth of 2, there will be 4 processes:
Fib(N-2),Fib(N-3),Fib(N-3), and Fib(N-4). The processor (say, P0)
computing Fib(N-2) will finish last, so the other processors idle time
can be measured against the difference between when they finish and
when P0 finishes. The sum of these time differences is proportional
to:
((fib n-2)-(fib n-3)) + ((fib n-2)-(fib n-3)) + ((fib n-2)-(fib n-4))=
((fib n-2) + (fib n-4))
Genralizing this, and assuming d>#P (#P = number of processors): There
are 2↑d processes, ranging from (fib n-d) to (fib n-2d). The number
of processes of each size is a binomial coefficient. If we schedule
these to run "largest first", which is a decent but not optimal bin
packing strategy, at some point near the end we'll have d processes of
size (fib n-2d+1) and 1 process of size (fib n-2d). One possiblity (i
think its the best possibilty), assuming 0 scheduler overhead, is that
all #P processors grab the last #P processes simultaneously. In this
case, 1 processor (computing (fib N-2d)), finishes before the other
#P-1 processors (computing (fib N-2d+1)). Thus, the total idle time
is proportional to just one term (since the other #P-1 processors
finish at the same time): ((Fib N-2d+1)-(Fib N-2d))=(FIB N-2D-1). If
you assume D is large with respect to #P, then (i think) this is a
lower bound on the idle processor time. With a fixed depth cutoff,
then, the percentage of idle time in computing (FIB N) is proportional
to 1/(PHI↑(2d+1)), or 1/(FIB 2d+1), as N goes to infinity.
This analysis is important for analyzing Nstack/qempty behavior, which
is non-trivial. My question is, is this analysis correct?
∂10-Mar-88 1125 Qlisp-mailer re: Amount of idle time with cutoff d in Fibonacci
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 11:25:29 PST
Received: from SAIL.Stanford.EDU by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04691; Thu, 10 Mar 88 11:25:41 pst
Message-Id: <8803101925.AA04691@Gang-of-Four.Stanford.EDU>
Date: 10 Mar 88 1125 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: Amount of idle time with cutoff d in Fibonacci
To: pehoushe@Gang-of-Four.Stanford.EDU, qlisp@Gang-of-Four.Stanford.EDU
[In reply to message from pehoushe@Gang-of-Four.Stanford.EDU sent Thu, 10 Mar 88 11:20:19 pst.]
I don't understand the point of this analysis. Surely, when a processor
finishes one task, there will be enough tasks on the queue so it can
pick up another.
∂10-Mar-88 1141 Qlisp-mailer Amount of idle time with cutoff d in Fibonacci
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 11:40:56 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA04748; Thu, 10 Mar 88 11:41:07 pst
Date: Thu, 10 Mar 88 11:41:07 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803101941.AA04748@Gang-of-Four.Stanford.EDU>
To: JMC@SAIL.Stanford.EDU
Cc: qlisp@Gang-of-Four.Stanford.EDU
In-Reply-To: John McCarthy's message of 10 Mar 88 1125 PST <8803101925.AA04691@Gang-of-Four.Stanford.EDU>
Subject: Amount of idle time with cutoff d in Fibonacci
The question is about the tail end of the computation, when almost all
of the spawned processes have been computed. There will be a very
small (if d is large) amount of idle time; the question is, How much?
My "analysis" says that the amount of idle processor time during
the computation of Fib(N), with depth cutoff d, is propportional to
1/fib(2d+1), assuming all the idle time comes at the very end of the
computation. That is, in the best case:
IDLE-TIME/TOTAL-COMPUTATION-TIME >= 1/fib(2d+1)
∂10-Mar-88 1306 Qlisp-mailer We Need An Accounting Equation
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 13:06:54 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05220; Thu, 10 Mar 88 13:07:06 pst
Date: Thu, 10 Mar 88 13:07:06 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803102107.AA05220@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Subject: We Need An Accounting Equation
I'd like to settle on a standard Accounting equation with which to
analyze various programs and schedulers.
Carolyn and I discussed several such equations, and it seemed like
several variations could be used. There should be a "simple summary"
equation encompassing all the costs we care about. My candidate is
the following equation:
Ttotal = Tcompute + Tidle + Tspawn + Tpredfalse + Tlocks
With the following definitions:
#P is the number of processors.
Ttotal is the total individual processor time, usually #P*elapsed-cpu-time.
Tcompute is the total time spent computing/doing useful work, and for
ordinary parallelism, Tcompute=Serial time on one processor.
Tidle is the total amount of time processors spend idling.
Tspawn is the time spent spawning processes (and swapping them).
Tpredfalse is the time spent evaluating the spawn predicate to false.
Tlocks is the time spent accessing and contending for locks.
Speed-Up is generally #P*Tcompute/Ttotal.
Really, the equation is just a list of COST CENTERS (an accounting term?)
which add up to the total cost.
An untouched accounting category is GC/memory-allocation overhead. Yuck.
Any one of these cost centers could be further broken down (to
individual locks, or contention time vs. access counts, or attributing
accesses to the run-queue lock as part of the spawning cost, etc.).
In most cases, we can ignore Tlocks by attributing the access cost to
spawn cost. When lock-contention becomes important, though, we need a
lock-contention cost center.
Accounting equations do not have much to do with QLISP The Language.
However, we need such terminolgy/equations to write coherent papers.
Nominations are open for better terminology, symbology, simpler, better
equations, etc.
∂10-Mar-88 1418 yuly@csv.rpi.edu
Received: from csv.rpi.edu by SAIL.Stanford.EDU with TCP; 10 Mar 88 14:17:04 PST
Received: by csv.rpi.edu (5.54/1.14)
id AA17150; Thu, 10 Mar 88 17:19:56 EST
Date: Thu, 10 Mar 88 17:19:56 EST
From: yuly@csv.rpi.edu (Liang-Yin Yu)
Message-Id: <8803102219.AA17150@csv.rpi.edu>
To: jmc@sail.stanford.edu
Dear Prof. McCarthy:
If you think the theories in my paper are somewhat worthy, I would
really like to know the chance to pursue it in the context of
nonmonotonic reasoning under your supervision. There is not really
much place where I can do it in this fashion, and I am encountering
a crossroad for the choice of my future. Please notify me, if
possible. If there are some difficulties in reading the paper, please
also let me know. Thank you.
Liang-Yin Yu
∂10-Mar-88 1420 MPS Flights
Leave Sunday, San Jose, PSA 0650 6:07
Arrive Burbank 7:05
Leave Wednesday, American West 1248 8:15
Arrive Phoenix 10;30
Leave Thursday, American West 884, 9:15
Arrive San Jose 10:00
Car reserved at LA
Pat
∂10-Mar-88 1459 pehoushe@Gang-of-Four.Stanford.EDU Oh, you meant "What's the Point of the previous analysis?"
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 14:59:49 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05577; Thu, 10 Mar 88 15:00:02 pst
Date: Thu, 10 Mar 88 15:00:02 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803102300.AA05577@Gang-of-Four.Stanford.EDU>
To: JMC@sail
Subject: Oh, you meant "What's the Point of the previous analysis?"
My reply did not exactly answer your question. The point of the
previous analysis is to PROVE that the Nstack/Qempty scheduler is very
good by favorably comparing it with something that everyone agrees is
very good. I don't yet know exactly how good Nstack/Qempty is, but it
certainly gets good results, and permits some very simple paralleism
constructs.
To analyze the Nstack/Qempty scheduler, I need to compare a problem
run on the Nstack scheduler, and a similar problem run on some other
kind of scheduler. I chose to compare Fib with a fixed depth cutoff,
on a zero overhead-for-spawning scheduler, and the Nstack/Qempty
scheduler, as currently implemented. The version with a fixed cutoff
has a certain small amount of non-parallelizability. I wish to
compare this SMALL amount of idle-time overhead with the amount of
spawning overhead in the Nstack/Qempty scheduler.
At first glance, it seems unfair to compare the zero
spawning-overhead scheduler to one in which it costs something to
spawn a process. However, the Nstack/Qempty scheduler is very good at
dynamically deciding whether or not it should spawn. The analysis of
Nstack/Qempty is not yet complete, but analaytically, it does "behave"
as though the depth cutoff is large and the spawning overhead is close
to nothing.
The Nstack/Qempty scheduler obtains quite good results. I am
putting more graphs of results together; however, I have presented
such results in the past. The current batch of empirical results (as
well as previous results) have clearly shown that the Nstack/Qempty
scheduler yields MORE speed-up than the single queue scheduler, in
addition to providing some SIMPLE parallelism constructs. So, the
real point of the analysis is to provide some evidence other than
empirical results showing that the NStack/Qempty scheduler is
extremely good, and should be used as the Qlisp scheduler. Such
a change could have a major impact on the Qlisp language, such as
something similar to the very simple parallel funcall, #!.
Qlisp Research Programmer,
Dan Pehoushek
∂10-Mar-88 1504 Qlisp-mailer Re: Amount of idle time with cutoff d in Fibonacci
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 15:03:39 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA05607; Thu, 10 Mar 88 15:03:50 pst
Date: Thu, 10 Mar 88 15:03:50 pst
From: Igor Rivin <rivin@Gang-of-Four.Stanford.EDU>
Message-Id: <8803102303.AA05607@Gang-of-Four.Stanford.EDU>
To: JMC@SAIL.Stanford.EDU, pehoushe@Gang-of-Four.Stanford.EDU
Subject: Re: Amount of idle time with cutoff d in Fibonacci
Cc: qlisp@Gang-of-Four.Stanford.EDU
I also don't quite understand the significance of this.
Since the overhead is not trivial in any actual computation, for d large
it will swamp the schedulling inefficiency for any non-trivial d.
What is somewhat interesting, is what happens for a small d --
This came up when Joe anmd I were doing the sorting experiments,
when quicksort breaks up the array to be sorted into rather unequal
pieces. The apparent solution to the "bin-packing" problem then was
simply to increase the number of processes spawned -- using Joe's
virtual processor concept, you act as if there were more processors
then there actually are, and hope that the spawning overhead is less signint
Then the efficiency engendered by spawning smaller processes. This
definitely appears to be the case. I seem to recall talking about this
at some meeting or other...
Also, I think FIB is not a good function to use, since the distribution
of task sizes is extremely special. A good question may be
"what is a representative distribution for sizes?"
It seems clear that it is not uniform, in any sense, but I am not
sure beyond that...
Igor
∂10-Mar-88 1619 perlis@yoohoo.cs.umd.edu a puzzle about introspection
Received: from gyre.umd.edu by SAIL.Stanford.EDU with TCP; 10 Mar 88 16:18:53 PST
Received: from yoohoo.cs.umd.edu by gyre.umd.edu (5.58/4.7)
id AA04745; Thu, 10 Mar 88 19:19:12 EST
Received: by yoohoo.cs.umd.edu (5.54/3.14)
id AA07636; Thu, 10 Mar 88 19:19:31 EST
Date: Thu, 10 Mar 88 19:19:31 EST
From: perlis@yoohoo.cs.umd.edu (Don Perlis)
Return-Path: <perlis@yoohoo.cs.umd.edu>
Message-Id: <8803110019.AA07636@yoohoo.cs.umd.edu>
To: BMOORE@STRIPE.SRI.COM, CGS.KAMP@R20.UTEXAS.EDU, THOMASON@C.CS.CMU.EDU,
jmc@sail.stanford.edu, konolige@stripe.sri.com, loui@cs.rochester.edu,
reiter%utai.toronto.edu@relay.cs.net, sjg@sail.stanford.edu,
utai!reiter@uunet.uu.net, val@sail.stanford.edu
Subject: a puzzle about introspection
Cc: CGS.ASHER@R20.UTEXAS.EDU, JEEM%TORONTO.CSNET@csnet-relay.arpa,
PHAYES@KL.SRI.COM, ether%allegra.att.com@relay.cs.net,
fagin%almvma.bitnet@wiscvm.wisc.edu, fagin@ibm.com,
grosof@sail.stanford.edu, halpern%almvma.bitnet@wiscvm.wisc.edu,
halpern@ibm.com, hector%utai.toronto.edu@relay.cs.net,
hector%toronto.csnet@csnet-relay.arpa, jbarnden%nmsu@relay.cs.net,
phayes@sri-kl.arpa, shoham@yale.arpa
I recently noticed an odd thing regarding negative introspection, which I
regard as the basis for default reasoning. Namely, if we conclude C on the
basis of A and of not knowing B:
A and -KB .-->. C
then the following situation can arise. Consider the simple example due to
Moore, where B is the proposition `I have an elder brother' and C is -B.
Specifically, we have
-KB --> -B
that is, not knowing one has an elder brother entails not having one.
Now, if the reasoner is given information which, taken together, indeed does
not entail B, and if it has an introspection-oracle so that it can infer
this fact, -KB, then modus ponens does the rest, giving -B.
Note that if the reasoner's information entails -B directly (without the use
of the introspection-oracle) then there is no need to invoke it, although
doing so is harmless enough. Moreover, the force of Moore's approach, like
that of most examples of non-monotonic reasoning, is to derive a result that
was not otherwise available. That is, the point of such reasoning is to aid
in deciding undecided cases, in which it is not known whether or not B is
true. For if either B or -B is already known then the issue is moot.
On the other hand, if neither B nor -B is so entailed, then the reasoner
cannot decide either -B or B without a default mechanism, which in turn
involves an introspection-oracle. Thus the indeterminate status of B is
what makes the oracle important for allowing a default conclusion. Yet in
precisely this case, not only do we have -KB but also -K-B! So the reasoner
knows neither -B nor B. But it should then come to realize this, i.e.,
realize the fact of indeterminacy: -KB and -K-B, rather than simply -KB.
Yet, on that basis, it is led to conclude -B after all! The result is that
both -B and -K-B are concluded by the reasoner! Thus there is (almost) an
inconsistency, which becomes blatant if there is also a positive
introspection-oracle to derive K-B from -B.
Now there is an obvious sense in which this can be explained: time has
passed between the (early) fact of -K-B and then later fact of -B's being
concluded, so that -K-B is no longer true once -B is concluded. But this
then calls for a very different analysis of default reasoning, it seems to
me. No longer is there the idealization of a fixed theory closed under
inferential operations.
As far as I can see, this bodes ill for formalizations of default reasoning
in single-theory frameworks. I would be interested in your reactions.
-Don
∂10-Mar-88 1713 CLT msg
call david c
∂10-Mar-88 2000 JMC
Opera Guyed
∂10-Mar-88 2010 Qlisp-mailer Re: Scheduler inefficiencies
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 20:10:35 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06445; Thu, 10 Mar 88 20:10:37 pst
Date: Thu, 10 Mar 88 20:10:37 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803110410.AA06445@Gang-of-Four.Stanford.EDU>
To: rivin@Gang-of-Four.Stanford.EDU
Cc: JMC@SAIL.Stanford.EDU, qlisp@Gang-of-Four.Stanford.EDU
In-Reply-To: Igor Rivin's message of Thu, 10 Mar 88 15:03:50 pst <8803102303.AA05607@Gang-of-Four.Stanford.EDU>
Subject: Re: Scheduler inefficiencies
Regarding swamping scheduler for non-trivial d. As we knew when
developing the Nstack scheduler on Joe's simulator back in August, any
non-trivial d will cause a QUEUE based scheduler to bomb, because
queues make the computation breadth first. That is, for depth d, all
2↑d processes get spawned before any "computation leaves" are reached.
This is bad, and was one motivation for a stack based scheduler.
Maybe a queue scheduler is more appropriate when there is a huge
memory and MANY processors, but it does not seem like a good idea,
even then. I forgot about this defect in the current QLISP
implementation, because I only use the N-stack scheduler, and have
never noticed any swamping due to scheduler inefficiencies, although
some computations do take a long time.
With a stack-based scheduler (single or multiple), the computation is
more depth first. Actually, it has #P depth first threads of control.
I pre-allocate 500 process shells in the Nstack scheduler, but I don't
think I have ever had more than 200 active processes at any time.
-QLP
∂11-Mar-88 0853 ball@navajo.stanford.edu Re: SAIL charges
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Mar 88 08:53:45 PST
Received: by navajo.stanford.edu; Fri, 11 Mar 88 08:49:47 PST
Date: Fri, 11 Mar 88 08:49:47 PST
From: James E. Ball <ball@navajo.stanford.edu>
Subject: Re: SAIL charges
To: JMC@sail.stanford.edu, ball@navajo.stanford.edu,
nilsson@score.stanford.edu
I know that it appears as though costs are rising on SAIL. What is
actually happening is that there is a decline in the user base resulting
in a larger charge per user. I was surprised to find that the costs for
running SAIL in 1981 were actually higher than they are at the present
time. According to numbers Arthur Keller dug up the cost for SAIL in
1981 were $417,869. The costs for the current period are estimated to
be $276,667 a decrease of approximately $141,000 per year.
One of the major concerns communicated to me when I took this position
was the serious situation occuring on SAIL. Unfortunately as the system
becomes less loaded the potential of having a single user bear the entire
burden become a reality. Shifting peoples salaries off SAIL and onto
other systems may be a solution if SAIL were taken out of the cost center.
It appears that one could reduce the costs a bit if billing and accounting
were not required.
I'm certainly willing to do anything required to keep SAIL available for
you. It is frustrating for me to see the person responsible for the system
unable to use it. The problem facing me is the rules established for shared
use facilities. A possibility might be to transfer the system out of the
cost center and reduce the cost center overhead, much like the Alliant is
handled now. Of course it would be difficult to reduce the hardware and
software maintenance costs very much since the system is so unique.
Jim
∂11-Mar-88 1040 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
SOME COMPUTATIONAL ASPECTS OF CIRCUMSCRIPTION
Phokion G. Kolaitis (KOLAITIS@NAVAJO)
Stanford University
Friday, March 11, 3:15pm
MJH 301
We explore the effects of circumscribing predicates in first-order formulae
from a computational standpoint. First, extending work of V. Lifschitz, we
show that the circumscription of any existential first-order formula is
equivalent to a first-order formula. After this, we investigate the
circumscription of Horn clauses. We show that a finite set of (universally
quantified) Horn clauses has a first-order circumscription if and only if
the associated logic program is bounded. It is known that boundedness is
an undecidable property of logic programs. Thus, it is an undecidable
problem to tell whether universal first-order formulae have a first-order
circumscription. Finally, we show that there are first-order formulae
whose circumscription has a coNP-complete model checking problem. This is
joint work with C.H. Papadimitriou.
∂11-Mar-88 1434 scherlis@vax.darpa.mil quarterly reports
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:33:57 PST
Received: from sun45.darpa.mil by vax.darpa.mil (5.54/5.51)
id AA06828; Fri, 11 Mar 88 17:31:00 EST
Posted-Date: Fri 11 Mar 88 17:23:14-EST
Received: by sun45.darpa.mil (5.54/5.51)
id AA08958; Fri, 11 Mar 88 17:23:16 EST
Date: Fri 11 Mar 88 17:23:14-EST
From: William L. Scherlis <SCHERLIS@vax.darpa.mil>
Subject: quarterly reports
To: SW-PI@vax.darpa.mil
Message-Id: <574122194.0.SCHERLIS@VAX.DARPA.MIL>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VAX.DARPA.MIL>
The last message I sent concerning quarterly reports requested
reports within one week of the end of the quarter. Expenditure
data is usually impossible to obtain this close to the time.
The deadline for quarterly reports is shifted to SIX WEEKS
after the end of the quarter. The next report is therefore
due in mid-May. Thanks,
Bill
-------
∂11-Mar-88 1445 FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: supercomputer center comments
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:45:50 PST
Date: Fri, 11 Mar 88 14:19:24 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: supercomputer center comments
To: JMC@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri, 11 Mar 88 13:53:00 PST
Message-ID: <12381567095.16.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
John, I'll be glad to sign it. I don't have the time to help draft it.
Sending such a statement is a good idea.
Ed
-------
∂11-Mar-88 1512 nilsson@Tenaya.stanford.edu supercomputer center comments
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Mar 88 15:12:34 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA11714; Fri, 11 Mar 88 15:12:32 PST
Date: Fri, 11 Mar 88 15:12:32 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803112312.AA11714@Tenaya.stanford.edu>
To: JMC@SAIL.stanford.edu
In-Reply-To: John McCarthy's message of 11 Mar 88 1353 PST <8803112213.AA11664@Tenaya.stanford.edu>
Subject: supercomputer center comments
I'll sign! -Nils
∂11-Mar-88 1633 VAL Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
NONMONOTONIC REASONING
IN A SYSTEM OF
CLAUSAL INTUITIONISTIC LOGIC
L. Thorne McCarty
Computer Science Department
Rutgers University
Friday, March 18, 3:15pm
MJH 301
Clausal Intuitionistic Logic is an extension of Horn clause logic which permits
the appearance of "negations" and "embedded implications" on the right hand
side of a rule, and interprets these new rules intuitionistically, in a set of
partial models. In this paper, we will develop a further extension of Clausal
Intuitionistic Logic which provides a general method for nonmonotonic
reasoning. We will define precisely the notion of a "default rule" and a
"default proof", using "negation-as-failure" in combination with true
intuitionistic negation, and we will argue that these definitions produce the
intuitively correct results in all the standard examples of default reasoning.
We will also develop a fixed point semantics for the default rules, and prove a
soundness and completeness theorem. One claim that we make for this system, as
opposed to other systems of nonmonotonic reasoning, is the following: The
nonmonotonic inferences in our system are no more difficult to compute than the
monotonic inferences, and the revision of a nonmonotonic conclusion is
incremental, requiring less computation than the original inference in most
cases. We will argue that these features are necessary in any theory of common
sense reasoning.
∂11-Mar-88 1645 SHOHAM@Score.Stanford.EDU lin
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 16:45:51 PST
Date: Fri 11 Mar 88 16:41:22-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: lin
To: jmc@Sail.Stanford.EDU
Message-ID: <12381592940.40.SHOHAM@Score.Stanford.EDU>
Fangzhen Lin has apparently not been accepted to our program. I think
it's a mistake, but won't try to change that on my own. I thought,
however, that you may interested in seeing him in, since he's doing
straight nonmonotonic logic stuff (despite my efforts to deter him),
and is truly exceptional.
Yoav
-------
∂11-Mar-88 1754 helen@psych.Stanford.EDU Hi there, got your message
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 17:54:12 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 11 Mar 88 17:52:44 PST
Date: Fri, 11 Mar 88 17:52:44 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: jmc@sail
Subject: Hi there, got your message
I've been sort of busy. Sorry I didn't get back to you sooner. I'll be
around here working tomorrow (Friday). How would it be if we got together
in the early afternoon and had lunch and tried out the simulator? Let
me know...
-helen
∂11-Mar-88 1857 helen@psych.Stanford.EDU re: Hi there, got your message
Received: from psych.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 18:57:12 PST
Received: by psych.Stanford.EDU (3.2/4.7); Fri, 11 Mar 88 18:55:44 PST
Date: Fri, 11 Mar 88 18:55:44 PST
From: helen@psych.Stanford.EDU (Helen Cunningham)
To: JMC@SAIL.Stanford.EDU
Subject: re: Hi there, got your message
Oh, ok. Yes I guess I don't know what I'm typing. How about
we meet at 2 p.m. tomorrow (Saturday) out front?
-helen
∂11-Mar-88 2128 binford@anaconda.Stanford.EDU supercomputer center comments
Received: from anaconda.Stanford.EDU.stanfo (Anaconda.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 11 Mar 88 21:28:52 PST
Received: by anaconda.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA05962; Fri, 11 Mar 88 21:34:23 PST
Date: Fri, 11 Mar 88 21:34:23 PST
From: binford@anaconda.stanford.edu (Tom Binford)
Message-Id: <8803120534.AA05962@anaconda.Stanford.EDU.stanford.edu>
To: JMC@sail.stanford.edu
Subject: supercomputer center comments
John
I am glad to sign the statement. I think that someone who
has better quantitative arguments would be right to draft
the statement, but call on me if thereis a need.
Tom
∂12-Mar-88 1134 HALPERN@IBM.COM Re: supercomputer center comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Mar 88 11:34:30 PST
Date: Sat, 12 Mar 88 11:32:36 PST
Sender: halpern@IBM.com
From: Joe Halpern <halpern@IBM.com>
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Message-ID: <880312.113236.halpern@IBM.com>
Subject: Re: supercomputer center comments
In-Reply-To: Your message of 11 Mar 88 1353 PST
John, I would like to sign a statement that proposes support for
researchers, not supercomputing. -- Joe
∂12-Mar-88 1243 CSL.ALLISON@Sierra.Stanford.EDU Re: supercomputer center comments
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 12:42:58 PST
Date: Sat 12 Mar 88 12:42:27-PST
From: Dennis Allison <CSL.ALLISON@Sierra.Stanford.EDU>
Subject: Re: supercomputer center comments
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 11 Mar 88 13:53:00-PST
Message-ID: <12381811590.12.CSL.ALLISON@Sierra.Stanford.EDU>
John--
I'd be happy to sign but I have not the time at the moment to assist
in drafting the statement.
-dra
∧
-------
∂12-Mar-88 1255 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: supercomputer center comments
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 12:55:17 PST
Date: Sat, 12 Mar 88 12:54:57 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: supercomputer center comments
To: JMC@sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri, 11 Mar 88 13:53:00 PST
Message-ID: <12381813865.18.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
THe supercomputer concept goes against the more natural grain of
distributed authority, responsibility, and computing attached to such
management.
I will insert, if you wish, such a paragraph, in a draft.
Gio
-------
∂12-Mar-88 1339 helen@white.stanford.edu Hi there, late as usual
Received: from white.stanford.edu by SAIL.Stanford.EDU with TCP; 12 Mar 88 13:39:43 PST
Received: by white.stanford.edu (3.2/SMI-3.0DEV3)
id AA17103; Sat, 12 Mar 88 13:33:16 PST
Date: Sat, 12 Mar 88 13:33:16 PST
From: helen@white.stanford.edu
Message-Id: <8803122133.AA17103@white.stanford.edu>
To: jmc@sail
Subject: Hi there, late as usual
How are you?
I started some laundry which is not yet done. I fear I will be
about 15 minutes late. Please reply if you receive this. I'll be
there about 2:15. See you!
-helen
∂12-Mar-88 1344 helen@Gang-of-Four.Stanford.EDU A second try
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 13:44:43 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02176; Sat, 12 Mar 88 13:44:51 pst
Date: Sat, 12 Mar 88 13:44:51 pst
From: Helen Cunningham <helen@Gang-of-Four.Stanford.EDU>
Message-Id: <8803122144.AA02176@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Subject: A second try
Hi there,
I'm not sure you got a message I just sent from White. It said I
will be about 15 minutes late. Now I'll try to find your phone
number. See you soon!
-helen
∂12-Mar-88 1345 helen@white.stanford.edu re: Hi there, late as usual
Received: from white.stanford.edu by SAIL.Stanford.EDU with TCP; 12 Mar 88 13:45:40 PST
Received: by white.stanford.edu (3.2/SMI-3.0DEV3)
id AA17122; Sat, 12 Mar 88 13:39:10 PST
Date: Sat, 12 Mar 88 13:39:10 PST
From: helen@white.stanford.edu
Message-Id: <8803122139.AA17122@white.stanford.edu>
To: JMC@SAIL.Stanford.EDU
Subject: re: Hi there, late as usual
Ok, got your reply. See you then!
-h
∂13-Mar-88 0140 DEK Yegorichev's book
To: rwg%russian.spa.symbolics.com@ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM
CC: JMC@SAIL.Stanford.EDU
Bill, I'm sorry about exercise 1.23; Ron has already made several corrections
to that. (He and Conway have some interesting examples, etc.) Please wait
for the real book on that one and move on to Chapter 2!
The book by Yegorichev that you mention may be the one that has been
translated into English, entitled "Integral Representation and the Computation
of Combinatorial Sums", AMS Translations of Mathematical Monographs, Vol. 59.
∂13-Mar-88 1304 Q4034%PUCC.BITNET@forsythe.stanford.edu test of mail
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Mar 88 13:04:23 PST
Received: by lindy.stanford.edu; Sun, 13 Mar 88 09:23:54 PST
Received: by Forsythe.Stanford.EDU; Sun, 13 Mar 88 13:04:05 PST
Received: by PUCC (Mailer X1.25) id 2924; Sun, 13 Mar 88 16:03:59 EST
Date: Sun, 13 Mar 88 16:01:45 EST
From: John Nash <Q4034%PUCC.BITNET@forsythe.stanford.edu>
Subject: test of mail
To: jmc@sail.stanford.edu
I am impressed by the big current role of Lithp (Lisp).
But does this e-mail addressing work here at this bitnet node?
This is a test.
∂13-Mar-88 1343 reif@cs.duke.edu Re: quarterly reports
Received: from vax.darpa.mil by SAIL.Stanford.EDU with TCP; 13 Mar 88 13:42:55 PST
Posted-Date: Sun, 13 Mar 88 16:39:33 EST
Received: from [128.109.140.1] by vax.darpa.mil (5.54/5.51)
id AA11450; Sun, 13 Mar 88 16:40:43 EST
Received: by duke.cs.duke.edu (5.54/DUKE/10-20-87)
id AA19034; Sun, 13 Mar 88 16:39:33 EST
Date: Sun, 13 Mar 88 16:39:33 EST
From: John H. Reif <reif@cs.duke.edu>
Message-Id: <8803132139.AA19034@duke.cs.duke.edu>
To: SCHERLIS@vax.darpa.mil, SW-PI@vax.darpa.mil
Subject: Re: quarterly reports
Dear Bill:
Sending a quarterly report sounds fine.
Could you send a message stating when the DARPA contract will start ?
I have gotten no official notice.
Best Wishes,
John
∂13-Mar-88 1354 Q4034%PUCC.BITNET@forsythe.stanford.edu letter
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Mar 88 13:54:27 PST
Received: by lindy.stanford.edu; Sun, 13 Mar 88 10:13:59 PST
Received: by Forsythe.Stanford.EDU; Sun, 13 Mar 88 13:53:55 PST
Received: by PUCC (Mailer X1.25) id 3009; Sun, 13 Mar 88 16:49:05 EST
Date: Sun, 13 Mar 88 16:29:15 EST
From: John Nash <Q4034%PUCC.BITNET@forsythe.stanford.edu>
Subject: letter
To: McCarthy <jmc@sail.stanford.edu>
Dear John,
I have been using REDUCE on time-sharing on the IBM3081 here.
This depends on Lithp for its programming structure. I have myself
learned only enough programming to do what I do using REDUCE.
So I don't actually know how the Lithp foundation actually works.
But in all that I read about the world of the use of computers
I find more and more about the use of Lithp.
And I have wondered about Prolog, which seems to be, to some
extent at least, considered an alternative to Lithp. As far as I
can see it looks like a commercial rivalry situation, one manufac-
turer's corn flakes or soap versus another's.
Certainly in the world of human speech dialects the situation
is one of arbitraryness. Spanish is a success not because of its
purity or logic but because certain conquistadores got a lot of
humans, spread over a wide area, to speak it.
And what of ADA ? My suspicion is that that idea is already
known to be stupid but that the fact of this knowledge is class-
ified ultra-top-secret because the DOD can't afford to allow
itself to look as if it had been stupid in 1979.
Best Regards,
J. Nash
Q4034@pucc.bitnet
∂13-Mar-88 1515 RDZ@Score.Stanford.EDU Shannon's paper
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 88 15:15:39 PST
Date: Sun, 13 Mar 1988 15:11 PST
Message-ID: <RDZ.12382100801.BABYL@SCORE.STANFORD.EDU>
From: RDZ@Score.Stanford.EDU
To: jmc@Sail.Stanford.EDU
Subject: Shannon's paper
It's back on your desk. You're right -- it contains absolutely no
mention of information theory.
I also found the calculation of just how many bits of memory were
needed to hold various tables quiet amusing....
Ramin
∂13-Mar-88 2339 SHOHAM@Score.Stanford.EDU re: lin
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 88 23:38:57 PST
Date: Sun 13 Mar 88 23:34:23-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: re: lin
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 11 Mar 88 17:35:00-PST
Message-ID: <12382192414.14.SHOHAM@Score.Stanford.EDU>
I don't. I know Andy Goldberg is on it. I'll ask.
Yoav
-------
∂14-Mar-88 0900 JMC
cash
∂14-Mar-88 1244 SHOHAM@Score.Stanford.EDU admissions committee chair
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 12:44:42 PST
Date: Mon 14 Mar 88 12:40:06-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: admissions committee chair
To: jmc@Sail.Stanford.EDU
Message-ID: <12382335449.50.SHOHAM@Score.Stanford.EDU>
I think it is indeed Genesereth
-------
∂16-Mar-88 1156 MKATZ@A.ISI.EDU Visit to Stanford
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 11:56:07 PST
Date: Tue 15 Mar 88 12:30:02-EST
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Visit to Stanford
To: m@Sierra.Stanford.EDU
cc: cheriton@Pescadero.Stanford.EDU, ag@pepper.Stanford.EDU,
dill@Amadeus.Stanford.EDU, jmc@SAIL.STANFORD.EDU, rpg@SAIL.STANFORD.EDU
Message-ID: <12382562992.45.MKATZ@A.ISI.EDU>
I am tentatively planning to visit Stanford on April 8 in order to discuss
graduate school oportunities. Please let me know if you anticipate being
available some time that day to talk with me so that I can firm up my plans.
Thank you,
Morry Katz
-------
∂16-Mar-88 1157 GINSBERG@Sushi.Stanford.EDU Reminder: NO FORMFEED TOMORROW
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 11:56:31 PST
Date: Wed 16 Mar 88 11:03:30-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: Reminder: NO FORMFEED TOMORROW
To: feed@Sushi.Stanford.EDU
Message-ID: <12382842153.13.GINSBERG@Sushi.Stanford.EDU>
We will meet again next week.
Matt
-------
∂16-Mar-88 1229 weening@Gang-of-Four.Stanford.EDU
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:29:07 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA02370; Tue, 15 Mar 88 11:01:19 pst
Date: Tue, 15 Mar 88 11:01:19 pst
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8803151901.AA02370@Gang-of-Four.Stanford.EDU>
To: jmc@sail, me@sail
From: boesch@VAX.DARPA.MIL
Newsgroups: comp.protocols.tcp-ip
Subject: Rumors about the death of the ARPANET
Message-ID: <8803141728.AA08682@sun46.darpa.mil>
Date: 14 Mar 88 17:28:20 GMT
Organization: The Internet
Lines: 83
There have been a number of rumors about the impending death of the
ARPANET. Here is the current DARPA position.
Brian Boesch
------------------------------------------------------------------------
DEATH OF THE ARPANET AND OTHER PARANOIA
There have been a number of rumors throughout the community that the
ARPANET project is being terminated. Many individuals and
organizations have expressed concern that the service that they have
become accustomed to will be terminated.
Enough rumors, now a word from your sponsor, DARPA.
The ARPANET project in fact is being terminated, but not soon. DARPA
is in the business of conducting research into critical NEW technologies
that will advance the state of the art. ARPANET is neither new,
nor state of the art. It is slow and expensive.
ARPANET was founded in the early 70's when 56Kbit/second trunks were
on the cutting edge of modulation and transmission technology. Packet
switching was unheard of. (An interesting fact is that the average
terminal of the day was 30cps giving the net trunks about a factor of
230 faster than the average user interface). Since that time the
project expanded into the INTERNET where a number of dissimilar
networks could be interconnected relatively transparently. The
internet grew from about 63 hosts to over 20,000. The local nets that
connect to the ARPANET and other Wide Area Nets (WANs) progressively
increased in speed. The result is that while in '73 a large number of
users could effectively share one trunk, today, one user on a PC can
overload the entire capacity of the ARPANET.
In addition to being overloaded, the ARPANET is no longer able to
support its other prime function, that of a research base. To conduct
any kind of experiment on the ARPANET causes too much service
disruption to the community.
Finally, the ARPANET is absorbing a significant fraction of our total
research budget in what is really a support function.
Solution, eliminate the source of the problem. Rather than cutting
off the community our approach is to outgrow the ARPANET in a few
years.
The follow on network experiment will be called the Defense Research
Internet (DRI). We are also working in conjunction with other Federal
agencies, most notably National Science Foundation, to integrate our
networking experiments with the new regional networks, the NSFNET
project, and other agency networks.
An additional source of confusion is the fact that we are currently
arranging for NSFNET to support some ARPANET users, as part of a joint
effort to reduce costs by phasing out overlapping service. Our
intention, as always, is to do this with minimal disruption to the
reserach community.
While this happening, we will be putting together the initial version
of the DRI apart from the ARPANET. From the beginning the DRI will provide
the long distance trunk capacity that the ARPANET lacks. Initial
speeds will be 1.5Mbit/second per link (a factor of 25 improvement).
The DRI will also be segregated into an "experimental" and an
"operational" side. The experimental side will have higher performance,
with the possibility of higher degree of net problems; the operational
side will support high data-rate applications such as image transfer.
The experimental side will be phased from 1.5Mbit to higher and higher
bandwidths with the intent of eventually reaching gigabit/second
performance; the operational side will take over for the ARPANET.
It will be operated by a contractor, and will be funded as overhead on
individual users' projects rather than becoming a drain on the Networking
research budget. After the DRI is stable, the ARPANET will be phased out.
PLEASE DON'T BURY US WITH QUERIES ON THE DETAILS OF THE
IMPLEMENTATION, WE DON'T HAVE TIME TO ANSWER THEM. AS DETAILS ARE
FINALIZED AND READY FOR PUBLIC DISSEMINATION, WE WILL POST THEM.
Mark Pullen & Brian Boesch
- -------
∂16-Mar-88 1313 SHOHAM@Score.Stanford.EDU so it is
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:13:07 PST
Date: Tue 15 Mar 88 08:51:10-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: so it is
To: jmc@Sail.Stanford.EDU
Message-ID: <12382555917.27.SHOHAM@Score.Stanford.EDU>
It's now official - MRG is the admissions chairman. Yoav
-------
∂16-Mar-88 1353 GINSBERG@Sushi.Stanford.EDU would either of you like to read a play this Sunday?
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:52:50 PST
Date: Wed 16 Mar 88 13:43:24-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: would either of you like to read a play this Sunday?
To: jmc@Sail.Stanford.EDU, clt@Sail.Stanford.EDU
Message-ID: <12382871261.39.GINSBERG@Sushi.Stanford.EDU>
Matt
-------
∂16-Mar-88 1358 Qlisp-mailer A proposed QDOTIMES syntax
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:58:01 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA06074; Wed, 16 Mar 88 13:30:42 pst
Date: Wed, 16 Mar 88 13:30:42 pst
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8803162130.AA06074@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
Cc: pehoushek@Gang-of-Four.Stanford.EDU
Subject: A proposed QDOTIMES syntax
The following is a proposed syntax for QDOTIMES:
(qdotimes number-of-processes (var countform [resultform])
{declaration}* {tag|statement}*)
Qdotimes should be used in cases where each iteration is independent
from the other iterations.
If number-of-processes is a number, then that many processes will be
spawned to work on the iterations. If number-of-processes is NIL,
then the scheduler will do the best it can using some heuristic.
Unless the programmer knows about some nice properties of the
iteration, it is highly recommended that number-of-processes be NIL.
I have implemented a version of this syntax. It works except for
throws and GCs. With Matrix Multiply, picking the "optimal" number of
processes results in a slight improvement (roughly O(2%)) over
number-of-processes NIL. If this syntax is acceptable, it can
easly be extended to the other list mapping iterators.
-QLP
∂16-Mar-88 2025 @Score.Stanford.EDU:adobe!plantin!rovner@decwrl.dec.com Follow-up on Yakov Eliashberg
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 20:24:54 PST
Received: from decwrl.dec.com by SCORE.STANFORD.EDU with TCP; Wed 16 Mar 88 20:20:47-PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04679; Wed, 16 Mar 88 20:25:25 PST
From: adobe!plantin!rovner@decwrl.dec.com
Received: from plantin.LOCAL (plantin.ARPA) by adobe.COM (4.12/4.7)
id AA00221; Wed, 16 Mar 88 17:28:53 pst
Received: by plantin.LOCAL (3.2/4.7)
id AA03994; Wed, 16 Mar 88 17:27:53 PST
Date: Wed, 16 Mar 88 17:27:53 PST
Message-Id: <8803170127.AA03994@plantin.LOCAL>
To: mccarthy@score.stanford.edu
Subject: Follow-up on Yakov Eliashberg
Cc: rovner@decwrl.dec.com
John,
18 months ago you were kind enough to wrote a letter on behalf of this fellow,
who was a long-term refusenik and a Soviet mathematician. I thought you would
be interested in what has happened since then, hence this note.
He was an invited speaker at ICM-86 in Berkeley, so we took that opportunity
to publicize his situation. He was refused again later that year, but finally
did receive permission this past November to emigrate (!!).
He and his family arrived in Palo Alto about a month ago (his brother and
elderly mother live here and are friends of mine). He has an appointment at
MSRI in Berkeley, starting in September (his field is Simplectic Geometry).
In the meantime, he and his wife are taking classes to improve their English,
learning to drive an automobile, and smiling a real lot. He has an office at
Berkeley in the Math Department and is giving a series of lectures there, too.
I thought you might be interested in meeting him. He is a remarkable guy.
And a chat with you would help him to orient himself professionally.
If you do have the time, you can reach him at home at 858-1849. Evenings are
probably best.
Best regards,
Paul Rovner
∂17-Mar-88 0405 @DIAMOND.S4CC.Symbolics.COM:rwg@RUSSIAN.SPA.Symbolics.COM Yegorichev's book
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by SAIL.Stanford.EDU with TCP; 17 Mar 88 04:04:07 PST
Received: from RUSSIAN.SPA.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 174097; Thu 17-Mar-88 07:04:59 EST
Received: from TSUNAMI.SPA.Symbolics.COM by RUSSIAN.SPA.Symbolics.COM via CHAOS with CHAOS-MAIL id 58246; Thu 17-Mar-88 03:41:13 PST
Date: Thu, 17 Mar 88 03:40 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: Yegorichev's book
To: DEK@SAIL.Stanford.EDU
cc: rwg%russian.spa.symbolics.com@ELEPHANT-BUTTE.SCRC.Symbolics.COM,
JMC@SAIL.Stanford.EDU
In-Reply-To: The message of 13 Mar 88 01:40 PST from Don Knuth <DEK@SAIL.Stanford.EDU>
Message-ID: <880317034031.9.RWG@TSUNAMI.SPA.Symbolics.COM>
Date: 13 Mar 88 0140 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Bill, I'm sorry about exercise 1.23; Ron has already made several corrections
to that. (He and Conway have some interesting examples, etc.) Please wait
for the real book on that one and move on to Chapter 2!
The book by Yegorichev that you mention may be the one that has been
translated into English, entitled "Integral Representation and the Computation
of Combinatorial Sums", AMS Translations of Mathematical Monographs, Vol. 59.
Aha, that's the one. Even I can understand Kombynatornikh Summ. I'll go sneak a
peek.
Two general worries about the book.
1. One way or another (PC Macsyma, Mathematica, Innovus, ...?) lots of students
are soon going to have their own computer algebra. It is much more fun to
implement symbolic math algorithms than to do ordinary programming, especially
if there is a lot of reading/parsing/displaying/plotting support already in place.
An excellent way to learn math is to teach it to your computer, especially when
it really is math, and not floating point arithmetic. Thus, a lot of concrete
math courses may be seduced by much shallower books which are more targeted to
introductory computer algebra.
2. Where's your right hemisphere? There are hardly *any* graphs or pictures in
there! I complained to Bug-Macsyma that Binom(x,y) rather badly embarrassed Plot3d
in the neighborhood of (-1,-1), and John Aspinall sent me some plots made with
his special software. "Pascal's Surface" turns out to be fascinating. With x held
fixed, you get an approximate sinusoid in y whose amplitude blows up and flips over
at every negative integer x. These x divide the surface into continuous strips
which only connect at integer y (where the sine is 0), but they connect along a
whole vertical line! That is, binom(-1+ε,-1+mε) has no jump as ε passes through
0, but at 0 the value is m, i.e. whatever was the slope of approach. Thus, letting
y approach each gridpoint ahead of x will give you the 0s you want at (-n,-k),
yet gives the asymmetrical, non-0 value at (-n,k-n).
A picture is worth 5kb. (But admittedly *costs* even more!)
∂17-Mar-88 0409 ARK SAIL Report
To: JMC
CC: ARK
Here's what I got from Jim Ball/Tom D.:
Salaries $93151
Benefits 24405
Total 117556
It's not clear exactly who that pays for. This is clearly
more that all of Marty and half of Don Coates. I still don't
know what else it consists of. (People and percentages is what
I asked for and didn't yet get.)
The following are allocations of "common costs".
Hardware 15% of 60000 9000
Software 20% of 20000 4000
bdg/wh/e 5% of 1700 85
trvl/sch 10% of 15000 1500
expendable 30% of 77500 23250
telecomm 10% of 40000 4000
Conduit 10% of 2000 200
Total so far 159591
Additional costs are:
Accounting 1/6 of 66895 11033
Comm&adm 30% of 133974 40192
Network 3960
Depreciation 35155
Carryover 400
Total $250331
Per month $20860
Here's what the budget might be if SAIL were taken private:
Salaries $93151 (could possibly be lower
Benefits 24405 if more people being
Total 117556 charged than necessary)
The following are allocations of "common costs".
Hardware 9000 (Hardware maint costs?)
Software 0 (SAIL doesn't buy software)
bdg/wh/e 85 (I don't know what this is....)
trvl/sch 0 (Who travels on SAIL business?)
expendable 23250 (With tapes, etc., who knows?)
telecomm 4000 (Phones and modems? OK)
Conduit 10% of 2000 200 (Sure....)
Total so far 154176
Additional costs are:
Accounting 1/6 of 66895 5000 (still need POs etc filed out)
Comm&adm 30% of 133974 0 (SAIL doesn't need this)
Network 3960 (SAIL would still pay this)
Depreciation 35155 (CF-purchased)
Carryover 400 (not much)
Total $198606
Per month $16551
It's not clear that this is enough of a savings to justify the change.
Also, it makes Marty's job on even softer money than it is now.
Arthur
∂17-Mar-88 0849 BSCOTT@Score.Stanford.EDU ARPA Formal Reasoning
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 88 08:49:01 PST
Date: Thu 17 Mar 88 08:44:59-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: ARPA Formal Reasoning
To: JMC@Sail.Stanford.EDU, CLT@Sail.Stanford.EDU
cc: Bergman@Score.Stanford.EDU, BScott@Score.Stanford.EDU
Message-ID: <12383079081.16.BSCOTT@Score.Stanford.EDU>
I have just talked with John Pucci at SPAWAR about the Formal Reasoning Task
on the umbrella contract. I had understood from you, John, that Col. Simpson
wanted quick turnaround on the equipment justification. He said in his message
to you that "the approval package is being held awaiting" the arrival of the
additional equipment information.
John Pucci tells me now that the extension of the umbrella contract has to
be renegotiated because of new federal rules. Indeed, I am now presenting
information to Stanford's Audit Liaison Office for purposes of a DCAA audit
which is in progress now. I expect that this will take the DCAA a week or
more here, and then who knows how long to get the report to SPAWAR so that
the funds can be released. Pucci says that it will be at least June before
you will see any funding on your Formal Reasoning Task. Pucci suggested that
you might wish to talk directly with Simpson at ARPA to see whether anything
can be done now to get partial funding to you prior to June.
Pucci also said that ARPA people are very slow in communicating anything to
him, and suggested that you ask Simpson to keep him as well-informed as
possible.
I will get update information to you as soon as I have any.
Betty
-------
∂17-Mar-88 1033 SHOHAM@Score.Stanford.EDU letter(s)
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 88 10:32:59 PST
Date: Thu 17 Mar 88 10:29:00-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: letter(s)
To: jmc@Score.Stanford.EDU
cc: bscott@Score.Stanford.EDU
Message-ID: <12383098014.28.SHOHAM@Score.Stanford.EDU>
John,
First, I'm curious whether there's been any progress on Lynn's case.
Have you approached MRG?
Now to the audacious part. I was embarassed by the praise in your letter,
but even so the lawyer we're using suggested strgthening both it
and Nils' letter. He proposed something like the following text.
Please let me know if you're willing to sign such a ridiculous thing.
Also, I will apply for the IBM faculty development award. May we use
your (original) letters as one of the recommendation letters?
Here it is:
This letter is in support of making an exception to the rule about
Fullbright scholars returning to their countries of origin in the case of
Professor Yoav Shoham in connection with his work as Assistant Professor
of Computer Science at Stanford University.
Shoham possesses an rare combination of skills,
which enable him to make a contribution to his field that only
a handful of people could. I can assert this with a degree of certainty
since Shoham's area happens to be my specialty also.
The field of using mathematical logic to express common sense
knowledge in a way that can be used by intelligent computer
programs started about thirty years ago.
Today, this specialty is important to maintaining the U.S. lead in
technology related to defense. The current DARPA research projects
in developing artificial intelligence systems for a pilots associate,
an autonomous land vehicle and naval battle management will all experience
performance limitations related to their ability to use common
sense knowledge.
Despite the thirty-year history,
progress in the area has been slow.
The main reason has been the shortage of people who combine the
necessary knowledge and ability in logic with the necessary
interest in, and deep insight about,
the basically non-mathematical problem of
common sense reasoning and problem solving. Such people are a
rare commodity, and Shoham is probably the best person to have joined this
group of specialists in the past five years.
Shoham's original conceptual approach may yield the best solution
to the problems we are facing. This is
evidenced by his PhD thesis and his more recent
work.
This is why we chose him for our faculty and why he is included in our
current DARPA project on developing the logic approach to artificial
intelligence.
It would be a tremendous loss to our country if Shoham were to leave,
and I urge you to make sure it does not happen.
Sincerely,
-------
∂17-Mar-88 1125 MPS phone call
Dr Cranberg from Austin would like you to call him
512 327-1794
∂17-Mar-88 1125 MPS Hi-noon lecture
Rick Reis@Sierra needs information on hi-noon lecture
for 4-15
Pat
∂17-Mar-88 1131 MPS Ltr of Reference
Judy Reinhart, University of Illinois (217) 244-0061.
She needs a letter of reference for Michael Farmwald, but
she did not send out a letter requesting said letter. She will
send one out if you insist, but what she really wants is for you
to call so she can explain this MESS
Pat
∂17-Mar-88 1331 MPS presentationn
John Deming would like to arrange a meeting with you so
he can bring his presentation to you. 851-0121
pat
∂17-Mar-88 1711 GENESERETH@Score.Stanford.EDU Re: supercomputer center comments
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 88 17:10:59 PST
Date: Thu 17 Mar 88 17:06:59-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: supercomputer center comments
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Fri 11 Mar 88 13:53:00-PST
Message-ID: <12383170467.41.GENESERETH@Score.Stanford.EDU>
John,
I will sign it, if the number of signers matters.
mrg
-------
∂17-Mar-88 1841 VAL Reminder: Commonsense and Nonmonotonic Reasoning Seminar
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
NONMONOTONIC REASONING
IN A SYSTEM OF
CLAUSAL INTUITIONISTIC LOGIC
L. Thorne McCarty
Computer Science Department
Rutgers University
Friday, March 18, 3:15pm
MJH 301
Clausal Intuitionistic Logic is an extension of Horn clause logic which permits
the appearance of "negations" and "embedded implications" on the right hand
side of a rule, and interprets these new rules intuitionistically, in a set of
partial models. In this paper, we will develop a further extension of Clausal
Intuitionistic Logic which provides a general method for nonmonotonic
reasoning. We will define precisely the notion of a "default rule" and a
"default proof", using "negation-as-failure" in combination with true
intuitionistic negation, and we will argue that these definitions produce the
intuitively correct results in all the standard examples of default reasoning.
We will also develop a fixed point semantics for the default rules, and prove a
soundness and completeness theorem. One claim that we make for this system, as
opposed to other systems of nonmonotonic reasoning, is the following: The
nonmonotonic inferences in our system are no more difficult to compute than the
monotonic inferences, and the revision of a nonmonotonic conclusion is
incremental, requiring less computation than the original inference in most
cases. We will argue that these features are necessary in any theory of common
sense reasoning.
∂18-Mar-88 0551 solvberg%vax.runit.unit.uninett@TOR.nta.no IFIP Working Conf. in China, July 4-8 '88, Visa for invited speakers.
Received: from tor.nta.no by SAIL.Stanford.EDU with TCP; 18 Mar 88 05:38:52 PST
Posted-Date: 18 Mar 88 14:26 +0100
Received: by tor.nta.no (5.54/3.21)
id AA27319; Fri, 18 Mar 88 14:28:40 +0100
Date: 18 Mar 88 14:26 +0100
From: Arne Solvberg <solvberg%vax.runit.unit.uninett@TOR.nta.no>
To: John Sowa <sowa%yktvmt.BITNET@TOR.nta.no>,
John McCarthy <JMC@sail.stanford.EDU>
Cc: Jianhua Yang <yang%norunit.BITNET@TOR.nta.no>
Message-Id: <376*solvberg@vax.runit.unit.uninett>
Subject: IFIP Working Conf. in China, July 4-8 '88, Visa for invited speakers.
To the invited speakers:
John McCarthy,
Raymond Reiter,
John Sowa,
We need your passport number in order to arrange for your visa
for China. Please inform us if your visa is arranged by somebody
else, so that we will know wether we have to concern ourselves.
Please inform us if you bring any accompanying person, and/or
if you want to participate in a post conference tour.
For your information, I also enclose the "e.mail" version of
CALL FOR PARTICIPATION for the working conference in which you
may find information about the post conference tour alternatives, etc.
Sincerely yours,
Arne Solvberg
PS: To John Sowa:
Dear John,
I don't have Raymond Reiter's e-mail address.
May I bother you to pass this message on to him?
Encl: CALL FOR PARTICIPATION.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
International Federation for Information Processing (IFIP)
CALL FOR PARTICIPATION
----------------------
IFIP WG2.6/WG8.1 Working Conference on
The Role of Artificial Intelligence in
Databases and Information Systems
July 4-8, Guangzhou, China
--------------------------------------------------
The Working Conference is about The Role of Artificial Intelligence
in Databases and Information Systems as well as about the role of
Databases in Artificial Intelligence based systems.
The Working Conference features the invited speakers:
John McCarthy, Stanford University: "Knowledge about knowledge
in databases";
John Sowa, IBM: "Knowledge representation in databases,
information systems and natural language";
Raymond Reiter, University of Toronto: "Integrity constraints
in databases and knowledge bases".
During the 5-day conference 30 additional papers will be presented,
selected from a large number of submissions.
The participation is limited to 75 non-Chinese scientists, and 75
Chinese scientists.
Group travel will be arranged from Europe. Post conference tours in
China will be arranged provided that there is enough interest for
participating in the various tour alternatives. There will be a
social program for accompanying persons during the conference.
Persons who want to participate are requested to register promptly,
because of time consuming organizational details, like getting a
visa, etc.
In case of overbooking, first priority is given to authors of
accepted papers, WG-members, TC-members, and persons who are
involved in the organization of the conference (e.g. PC-members).
Next, authors of rejected papers and persons who are already on the
guest-lists of WG2.6 and WG8.1 will be invited to fill up the
remaining slots. Third priority is given to scientists without any
previous affiliation to IFIP-activities.
<paging ----------------------------------------------------------->
ORGANIZATION:
General Conference Chairperson:
A. Solvberg, Norwegian Inst. Techn., Univ. Trondheim, Norway
Program Committee Chairpersons:
R. Meersman, Univ. Tilburg, The Netherlands
C.H. Kung, Univ. Iowa, USA
Conference Co-Chairpersons:
S. Sa, People's Univ., P.R. China
C.S Tang, Academia Sinica, P.R. China
Conference Secretary:
J.J. v. Griethuysen, Philips, The Netherlands
Organization Committee:
K. Xu, P.R. China (Chair)
Z. Shi, P.R. China (Secretary)
Q. Yao, P.R. China (Local Arrangements)
S. Chen, P.R. China
Y. Gu, China
G. Wu, P.R. China
J. Yang, Norway
Program Committee:
R. Balzer USA E. Neuhold F.R. Germany
D. Beech USA G.M. Nijssen Australia
J. Bubenko Sweden A. Olive Spain
Y. Chen China A. Pirotte Belgium
E. Falkenberg The Netherlands R. v.d. Riet The Netherlands
M. Fox USA A. Robinson USA
A. Furtado Brazil C. Rolland France
C. Furukawa Japan E. Sandewall Sweden
H. Gallaire F.R. Germany H.J. Schneider F.R. Germany
G. Gardarin France A. Sernadas Portugal
F. Golshani USA Z. Shi China
L. Kerschberg USA L. Siklossy The Netherlands
R. Lee USA A. Solvberg Norway
V. Lum USA J. Sowa USA
L. Mark USA R. Stamper UK
J. Minker USA G. Wiederhold USA
M. Morgenstern USA B. Yao USA
B. Moulin Canada C. Zaniolo USA
<paging ----------------------------------------------------------->
FULL PAPERS (45 min.):
----------------------
Cauvet C., Proix C., Rolland C.: "Information systems design:
an expert system approach", France.
Dubois E.: "Logical support for reasoning about the specifica-
tion and the elaboration of requirements", Belgium.
Esculier C.: "Inheritances with exceptions: an approach based
on semantic tolerance", France.
Falkenberg E.D., van Kempen H., Mimpen N.: "Knowledge-based
information analysis support", F.R. Germany.
Jiang Y.J.: "A self-referential relational data model", UK.
Lum V., Wu T., Hsiao D.: "Integrating advanced techniques into
multimedia DBMS", USA.
Neuhold E.J., Schrefl M.: "A knowledge-based approach to
overcome structural differences in object oriented database
integration", F.R. Germany.
Nguyen G.T., Rieu D.: "Heuristic control on dynamic database
objects", France.
Qian W., Zhao Z.: "Temporal reasoning in DB", P.R. China.
Rundensteiner E.A.: "The role of AI in DB's versus the role of
DB theory in AI: an opinion", USA.
Schiff J.: "The design of a knowledge based economic modeling
tool (EMT) prototype", F.R. Germany.
Sernadas C., Fiadeiro J., Sernadas A.: "Object-oriented
conceptual modeling from law", Portugal.
Shao J., Bell D. A., Hull M.E.C.: "LQL: A unified language for
deductive database systems", UK.
Tang C., Yin B.: "Data dependency and undecidability in a model
of historical information system", P.R. China.
Twine S.: "Representing facts in KEE's frame language",
Australia.
Wan J.-C., Zhou C.-H.: "MEX-1: an expert system shell", P.R.
China.
Wieringa R., van de Riet R.: "Algebraic specification of object
dynamics in knowledge base domains", The Netherlands.
Wohed R.: "Diagnosis of Conceptual schemas", Sweden.
Zaniolo C., Sacca D.: "Rule rewriting methods in the implemen-
tation of the logic data language LDL", USA.
Zeng H., Tong Q., Yao W., Song X.: "HITKMS: a knowledge base
machine system supporting cooperative expert-system and
experiential learning", P.R. China.
Zhang C., Tzu Y.: "A model for maintaining compiled Prolog
databases", P.R. China.
Zhou L., Yang D., Fan Z., Zhu L.: "QKBMS/75 -- A knowledge base
management system growing from relational DBMS and logic
programming language", P.R. China.
SHORT PAPERS (20 min.):
-----------------------
Berztiss A.T.: "On information-control systems, object
orientation, and expert systems", USA.
Demolombe R., Illarramendi A., Blanco J.M.: "Semantic
optimization in data bases using artificial intelligence
tech.s", France.
Potter W.D., Nute D.: "d-KDL: an EDS environment incorporating
defeasible reasoning", USA.
Reimer U.: "On enriching the semantics of knowledge representa-
tion models: a claim and an approach", F.R. Germany.
Su B., Shi C., Wang K., Hu P., Shi H., Wang J.: "The architec-
ture of a distributed knowledge base system", P.R. China.
Shao J., Yao Q.: "A Knowledge-based query optimization system",
P.R. China.
Tang C.S., et. al.: "To connect the informal graphical design
methodology with the formal specification in information
system design", P.R. China.
van Assche F., Loucopoulos P., Speltincx G.: "A rule-based
approach to the development of information systems", Belgium.
<paging ----------------------------------------------------------->
DETAILS OF THE ARRANGEMENT ARE:
Conference fees:
The conference fee will be approx. USD 250. There will be a
social program for accompanying persons during the conference,
approx. 20-25 USD/day/person, including lunches.
Hotels:
The recommended hotel is:
East (Dong Fang) Hotel:
Double room .......... 40 USD/day
Single room .......... 30 USD/day
A limited number of guest rooms of the Scientific Garden
Building of "Guangzhou Association for Science & Technology"
(GAST) may be available:
Double room .......... 20 USD/day
Single room .......... 12 USD/day
The prices include breakfast.
Group travel from Europe:
Provided that there is enough interest, there will be arranged
a group travel from Europe. The details are:
Price: Approx. 2000 Swiss Francs, from any European country.
Outward trip July 1, evening, to Guangzhou via Hong
Kong. Individual returns from either Beijing or Hong
Kong.
<paging ----------------------------------------------------------->
Post conference tour alternatives:
There will be arranged post conference tours, if there are
enough participating persons (min. 10 persons for each tour
alternative). The details are:
Tour no. 1: July 9-17,
Guangzhou - Guilin - Xian - Beijing
Prices: 780 USD/person, in double room
900 USD/person, in single room
Tour no. 2: July 9-17,
Guangzhou - Xian - Chongqing - (boat) -
Yichang - Wuhan - Shanghai
Prices: 820 USD/person, in double room
940 USD/person, in single room
Transport to Beijing or Hong Kong is extra
Tour no. 3: July 9-12,
Guangzhou - Guilin - Guangzhou
Prices: 335 USD/person, in double room
390 USD/person, in single room
Tour no. 4: July 9-24
Guangzhou - Guilin - Xian - Chongqing - (boat) -
Yichang - Wuhan - Shanghai - Beijing
Prices: Approx. 1200 USD/person, in double room
1300 USD/person, in single room
NOTE: Please specify tour numbers in the order of preference in
the application form.
More about the post conference tours:
Guilin: beautiful landscape with rivers, hills, rocks, etc.
Boat trip on the Lijiang River.
Xian: with one of the oldest universities in the world and the
famous grave of thousands of statues of soldiers.
Chongqing: an important city in Chinese history.
Yichang: a 3-day boat tour on the Yangtze River from Chongqing
to Yichang will be an unforgettable experience.
Wuhan: the city where the first shot against the last dynasty
was fired.
Shanghai: the biggest industry city in China, the oldest and
most important port to the western.
Beijing: the capital of China, with many historical monuments
like the Forbidden City, Summer Palace, etc. A one-day
tour to the Great Wall from Beijing will make your China
visit even more unforgettable.
<paging ----------------------------------------------------------->
APPLICATION FOR PARTICIPATION
-----------------------------
IFIP WG2.6/WG8.1 Working Conference on
The Role of Artificial Intelligence in
Databases and Information Systems
July 4-8, 1988, Guangzhou, China
---------------------------------------------------------
! NB Deadline for application is March 7, 1988 NB !
---------------------------------------------------------
Name________________________________________________________________
Last First Middle
Title_______________________Position________________________________
Nationality______________________Passport No________________________
Affiliation_________________________________________________________
Address_____________________________________________________________
____________________________________________________________________
____________________________________________________________________
City_____________________________State______________________________
ZIP______________________________Country____________________________
Phone_______________________________________________________________
Telefax_____________________________________________________________
Net Address_________________________________________________________
____________________________________________________________________
Accompanying persons (name, nationality, passport no.):
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
<paging ----------------------------------------------------------->
Wish to participate in group travel from Europe:
Yes_____
If yes, number of persons: _____
No _____
Wish to return Europe from:
Beijing:_____ Hong Kong:_____ Other: ________________
Wish to participate in post conference tour:
Yes_____ tour no: _____ _____ _____ _____
If yes:
No _____ number of persons: _____
Accompanying persons wish to participate in the full social program:
Yes_____
If yes, number of persons: _____
No _____
Primary hotel choice (please write the number of persons in the
relevant box(es)):
East (Dong Fang) Hotel:
Double (40 $/day) _____
Single (30 $/day) _____
Guest rooms of GAST:
Double (20 $/day) _____
Single (12 $/day) _____
<paging ----------------------------------------------------------->
Application forms should be sent to:
Jianhua Yang
Department of Electrical Engineering and Computer Science
The Norwegian Institute of Technology
The University of Trondheim
N-7034 Trondheim
Norway
phone: +47-7-593677
+47-7-594460
facsimile:+47-7-594466
e.mail: yang@norunit.BITNET
yang%vax.runit.unit.uninett@tor.nta.no
yang@idt.unit.no
within March 7, 1988.
=============
Electronic mail applications are also acceptable.
<end of the CALL FOR PARTICIPATION -------------------------------->
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
∂18-Mar-88 0904 CLT taxes
we should make an appt with okner
its so late now i don't know if he will take us
any constraints on meeting times
will you possibly be out of the country on april 15 so we can postpone?
∂18-Mar-88 1019 CLT pills
again i find pills in your bathroom within easy reach of
Timothy. this makes me extremely upset.
do you not care in the least????
∂18-Mar-88 1354 MPS grades
I am bringing Vladimir`s grades to the Old Union on
Monday. They are due on the 22nd. Can I bring yours
over also?
Pat
∂18-Mar-88 1405 LIBRARY@Score.Stanford.EDU tech report
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 14:04:18 PST
Date: Fri 18 Mar 88 14:00:10-PST
From: Math/Computer Science Library <LIBRARY@Score.Stanford.EDU>
Subject: tech report
To: jmc@Sail.Stanford.EDU
Message-ID: <12383398600.20.LIBRARY@Score.Stanford.EDU>
Prof. McCarthy:
Regarding tech report 024652 (*Simplification by Cooperating Design
Procedures*): we found an archive copy and made a circulating copy
from it. Therefore you need not worry about replacing it or
paying replacement costs. Sorry to trouble you about it --
Ina Roy
Math & CS library
-------
∂18-Mar-88 1551 MPS telephone
david chudnovsky called at 3:50. Left no message
Pat
∂18-Mar-88 1714 VAL Nonmonotonic seminar: no meeting
To: "@CS.DIS[1,VAL]"@SAIL.Stanford.EDU
From: Vladimir Lifschitz <VAL@SAIL.Stanford.EDU>
There will be no meeting next Friday, March 25.
∂18-Mar-88 2327 FEIGENBAUM@SUMEX-AIM.Stanford.EDU Are we having fun yet?
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 23:27:22 PST
Date: Fri, 18 Mar 88 21:57:36 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Are we having fun yet?
To: rindfleisch@SUMEX-AIM.Stanford.EDU, engelmore@SUMEX-AIM.Stanford.EDU,
nilsson@tenaya.Stanford.EDU, jmc@sail.Stanford.EDU, tob@sail.Stanford.EDU,
genesereth@score.Stanford.EDU
cc: buchanan@SUMEX-AIM.Stanford.EDU, shortliffe@SUMEX-AIM.Stanford.EDU
Message-ID: <12383485516.11.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
On Thursday (3/17/88), I attended a meeting in Washington,
called by Craig Fields and Jack Schwartz to discuss the
AI/DARPA funding situation. Also present were three from CMU
(Newell, Simon, and Reddy), Winston, Feldman, Heilmeier,
Waltz, Poggio, Amarel, Kahn, Raibert, and John Hopcroft (I
think that's all, but maybe I forgot one).
Fields indicated that he had called the meeting because of
the rising level of complaints he had heard about how the AI
community was being treated. He wanted to air it all out,
and gather up ideas for new funding directions for AI.
Schwartz opened his part of the meeting on a generally
conciliatory note as regards his goals in the AI area (to
wit, that there is no greater enthusiast for AI in the long
run; his uneasiness was with what AIers are doing NOW, with
exception of vision and speech). Most important, he
indicated budget levels of FY88= $35M, FY89=$35M and
FY90=$40M. That is, his uneasiness translated into:
a) don't increase AI funding for this year and next, but
don't decrease it either.
b) increase it in FY90.
Overall, not too bad, if he sticks with this.
The long meeting was quite acerbic and unproductive of
ideas, i.e. it was quite political and testy, and not
technical or creative. EArly in the meeting, Simon made a
long speech, summarizing how he saw AI's accomplishments and
challenging Schwartz's capability to make good technical
judgments about this progress.
Jack seems to be down on current approaches to "full AI", an
undefined term that roughly corresponds to phrases one often
hears: "really AI" and "truly AI". "Full AI" means something
like:
not limited approaches, not expert systems (because they're
too specialized, albeit smart)(but paradoxically these more
limited approaches to AI are not in deep trouble because
Jack sees their goals as being appropriately limited, hence
some progress can be made).
I sketched an assessment of present-state-of-research-on-
full-AI, and possible future initiatives (very briefly). The
one that seemed to capture Craig's attention was one on
machine learning.
Because of the makeup of the group, logic was hardly
mentioned during the day. Feldman briefly mentioned his
sympathy for some sort of connectionist initiative, but also
strongly dissociated himself from neural net research and
also from most of the other connectionists. Although he
didn't use these terms, it seemed that he sees a few sane
ones and a lot of not-so-sane ones. Incidentally, Jerry will
be coming out to the Bay Area (Berkeley) soon to head that
new German-government-sponsored institute that we made a
play for a few years ago.
Finally, Jack said privately after Craig left that if Craig
didn't like the decisions he was making, Craig could fund
the AI work he wanted to fund through some other office, or
start a new office, i.e. Jack was pretty set on doing
whatever it is he has decided to do.
Oh, yes. He said (publicly) that he wasn't much taken with
the large-knowledge-base-for-science-and-engineering work
that I am about to propose, so I'll be interested to see at
what level he funds it (zero? half? full?). I was glad to
see that Simon liked the idea. But that's the way the day
went.
-------
∂19-Mar-88 0252 GLB
I have put in your mailbox a sketch of a paper--the result of my recent work
with Jussi---and a dissertation proposal. The paper should be chapter II.
I hope that, with the help of Jussi, the ambitious implementation project
described in the proposal may materialize soon.
Gianluigi
∂19-Mar-88 1047 CLT 13mar notes on algol again
Oles, F.
[1985]
Type algebras, functor categories, and block structure
in
Nivat, M. and Reynolds, J.C. (eds)
Algebraic methods in semantics
pp. 544--573.
Use of functor categories to explain semantics of (ALGOL like languages) with
(1) rich type structure
(2) higher-order procedures, of arbitrarily complex type
(3) imperative capabilities
(4) block structure
Language translated uniformly to
Desugared Algol over `appropriate setting'
AS:
syntactic components -- \scrD,Op,Id
semantic components -- Val,mOp,\Sigma
\scrD -- poset of storable data types (ordering interpreted as coercions)
Op operators with functions
arity \in Op -> \scrD↑*
res \in Op -> \scrD↑
Val \in \scrD↑ -> Set
mOp g \in Val arity(g) -> Val res(g)
\Sigma -- category of store shapes (with expansion morphisms)
\scrP - poset of primitive phrase types
\delta-expression
\delta-variable
\delta-acceptor
for each data type \delta in \scrD
\delta \le \delta' \limp
\delta-exp \le \delta'-exp
\delta-acc \le \delta'-acc
\delta-var \le \delta'-exp
\delta-var \le \delta'-acc
\scrT - poset of phrase types -- generated as free algebra over \scrP
G typed set of generators
Op \cup Op' plus function type:G -> \scrT
type(g) = \delta_1-exp => ... => \delta_n-exp => \delta-exp
if g \in Op and arity-res(g)= \delta_1 ... \delta_n -> \delta
g \in Op' type g
skip comm
; comm
:={\delta} \delta-acc => \delta-exp => comm
ifthenelse{\tau} bool-exp => \tau => \tau => \tau
rec{\tau} (\tau => \tau) => \tau
newvar{\delta} (\delta-var => comm) => comm
[?? how are phrases of type \delta-var => comm created? -- by abstraction]
\scrL - the set of phrases (the language)
g, [x], [l m], [\lambda x:\tau.l]
for
g \in G; x \in Id; l,m \in \scrL, \tau in \scrT
Examples
letrec x:\tau be m in n
== [[\lambda x:\tau] [rec{\tau}[\lambda x:\tau.m]]]
begin \delta-var x; c end
== [newvar{\delta}[\lambda x:\delta-var.c]]
houses
we can see the Eltheringtons house tonight at 5:30
We have an appt with the realestate agent tomorrow at 11am
to see the best two of those he showed us yesterday
∂19-Mar-88 1049 CLT oops
the message is at the bottom of the page
here it is again
we can see the Eltheringtons house tonight at 5:30
We have an appt with the realestate agent tomorrow at 11am
to see the best two of those he showed us yesterday
∂19-Mar-88 1240 CLT oops
We will need to take Timothy with us as Hazel will want to leave by 5.
Do you want to bring Timothy and pick me up at 5:15?
If so, you should tell Hazel what the plan is and also
ask if she needs any cash.
∂20-Mar-88 1548 barwise@russell.stanford.edu common knowledge
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 20 Mar 88 15:48:26 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Sun, 20 Mar 88 15:53:20 PST
To: JMC@sail
Subject: common knowledge
Date: Sun, 20 Mar 88 15:53:19 PST
From: Jon Barwise <barwise@russell.stanford.edu>
John, Could you give me some references (better yet, reprints) to your
work where you discuss common knowledge. Especially relevant would be
any place where you criticisize the iterate approach.
I want to revise the historical remarks in my paper.
Jon
∂20-Mar-88 1826 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU triangles
Received: from ucscd.UCSC.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 88 18:26:31 PST
Received: by ucscd.UCSC.EDU (5.57/1.1)
id AA08608; Sun, 20 Mar 88 18:28:01 PST
Date: Sun, 20 Mar 88 18:28:01 PST
From: beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU (20012000)
Message-Id: <8803210228.AA08608@ucscd.UCSC.EDU>
To: jmc@sail.stanford.edu
Subject: triangles
The isoceles triangle with base 2 and height sqrt(7) is not embeddable
in Z↑3. Reason: the equations
7(a↑2 + b↑2 + c↑2) = u↑2 + v↑2 + w↑2 ; au+bv+cw=0
have no solution in integers, because they have no solution mod 16.
I checked that by computer, I don't know of a more human proof.
So now we know:
(1) for all dimensions it is NECESSARY that the tangents all have
rational squares.
(2) In dimension 5 and greater it is also SUFFICIENT.
(3) In dimension 3 it is NOT SUFFICIENT, as the example above has
all tangents having rational squares.
Question: is there a triangle embeddable in Z↑4 which is not embeddable
in Z↑3?
∂20-Mar-88 2118 CLT
is there any reason why we still pay for computer accounts for
givan
tepper
yuen
??
∂21-Mar-88 0032 LIN draft
Hi, John,
Yoav asked me to give you a copy of my unfinished draft on a rule-based
logic for commonsense reasoning (hoping this may be helpful for changing
my bad situation). I did it and just left a copy in your mail slot.
So far the logic works fine. It is computable at most of time. It not
only can do temporal projection, but also can do temporal explanation.
It includes nonmonotonic inheritance hierarchies as a special case and
it can be used to formalizing the ``negation as failure'' technique in
logic programming. And I hope it is a good logic to do commonsense reasoning.
Of course I'll be gratefull if you can look at it and let me know what
you think of it.
Thanks a lot,
-Fangzhen Lin
∂21-Mar-88 0044 CLT find yuen
>Yuen, Lun-Shin - MSCS Student [LSY:]
* LUN@Sushi
hasn't logged in for over a year.
If you can't remember who it is, then I suggest
we flush
∂21-Mar-88 0048 CLT find yuen
>Yuen, Lun-Shin - MSCS Student [LSY:]
* LUN@Sushi
hasn't logged in for over a year.
If you can't remember who it is, then I suggest
we flush
∂21-Mar-88 0918 MPS Trip to Washington
Leave SFO Mar 23 at 12:25 pm - United 20
Arrive Dulles 8:09 pm
Leave Dulles 5:30 Mar 25 - United 57
Arrive SFO 8:03 pm
Reservation at the
Holiday Inn
2101 Wisconsin Avenue, NW
Phone (202) 338-4600
∂21-Mar-88 0948 CLT Okner
wed 23 mar 16:30
[please confirm that this time is ok]
∂21-Mar-88 1103 MPS taxes
Taxes on Wednesday 3-30 at 9:00
∂21-Mar-88 1132 jcm@ra.stanford.edu statement to Congress on supercomputers
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:32:51 PST
Received: by ra.stanford.edu (4.0/SMI-DDN)
id AA15454; Mon, 21 Mar 88 11:32:59 PST
Date: Mon, 21 Mar 88 11:32:59 PST
From: jcm@ra.stanford.edu (John Mitchell)
Message-Id: <8803211932.AA15454@ra.stanford.edu>
To: JMC@sail.stanford.edu
Subject: statement to Congress on supercomputers
I strongly support this. Here are some minor editorial
suggestions, in braces {}, that may be of some use to
you. Ignore them if they are not.
------------
We are concerned that the present NSF emphasis on
supercomputer centers and engineering research centers
is having an adverse effect on research in computer
science by drastically reducing NSF support for individual
and small group research in computer science.
As in other sciences, almost all of the advances in computer
science to date has {have} been the result of research by
individuals and small groups.
This is the most flexible way of doing research and the one that
gives the best opportunities for young researchers to make innovations.
The only justification for a large basic research organization is when
{an} expensive research {facility} facilities, e.g. a particle accelerator,
is necessary
to do the research at all. In the early days, laboratories with
tens (but not hundreds) of researchers played an important role
in computer science, because laboratories of that size were necessary in
order to afford adequate computer facilities. With the advent of
computer workstations, the cost of providing an individual researcher
with individual computer facilities for most kinds of computer research
is now in reasonable relation to his salary. Departmental facilities
provide an important supplement.
The emphasis on research centers leads in the long run (ten years)
to domination of research by established ideas and by the most
active administrators rather than by the best researchers.
{is there evidence for this that can be cited? Maybe a comparison
with some other field?}
For these reasons we believe the recent emphasis on
supercomputer centers and engineering research centers has
had significant detrimental side-effects on American computer
science. {A telling symptom is that}
The symptom noted is that {relatively small} proposals with excellent
ratings by the reviewers are often not funded or funded at
very reduced levels.
The issue of individual grants vs. supercomputer centers
and engineering research centers is independent of the issue of merit
vs. geography in the awarding of grants.
{I don't follow the second "vs." ... somehow the sentence doesn't
make sense to me}
∂21-Mar-88 1150 WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: statement to Congress on supercomputers
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:50:29 PST
Date: Mon, 21 Mar 88 11:51:23 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: statement to Congress on supercomputers
To: JMC@SAIL.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon, 21 Mar 88 11:13:00 PST
Message-ID: <12384161590.64.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
I can support that. Gio
-------
∂21-Mar-88 1202 GENESERETH@Score.Stanford.EDU Re: Lin Fangzhen
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 12:02:37 PST
Date: Mon 21 Mar 88 11:52:00-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Lin Fangzhen
To: JMC@Sail.Stanford.EDU
cc: shoham@Score.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Sun 20 Mar 88 23:31:00-PST
Message-ID: <12384161701.51.GENESERETH@Score.Stanford.EDU>
John,
We had many very good applicants this year. Lin was weak on all gres.
His best showing was 95 percentile on quant, much lower on
analytical and cs. Terrible on verbal (17). His grades were not
stellar. His recopmmendations included assessments from top 5%
to top 25%. In his case it was not even a close decision.
mrg
-------
∂21-Mar-88 1340 HALPERN@IBM.COM Re: statement to Congress on supercomputers
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 13:40:23 PST
Date: Mon, 21 Mar 88 13:31:03 PST
Sender: halpern@IBM.com
From: Joe Halpern <halpern@IBM.com>
To: John McCarthy <JMC@SAIL.Stanford.EDU>
Message-ID: <880321.133103.halpern@IBM.com>
Subject: Re: statement to Congress on supercomputers
In-Reply-To: Your message of 21 Mar 88 1113 PST
John, I support your statement on supercomputing. Please add my name
to the list of signatories. -- Joe
∂21-Mar-88 1344 GENESERETH@Score.Stanford.EDU re: Lin Fangzhen
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 13:44:54 PST
Date: Mon 21 Mar 88 13:40:43-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: re: Lin Fangzhen
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 21 Mar 88 13:41:00-PST
Message-ID: <12384181493.53.GENESERETH@Score.Stanford.EDU>
John,
I will leave his folder with your secretary. You can see what we had
to go on.
mrg
-------
∂21-Mar-88 1446 jlh@vsop.stanford.edu Re: statement to Congress on supercomputers
Received: from vsop.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Mar 88 14:46:53 PST
Received: by vsop.stanford.edu; Mon, 21 Mar 88 14:44:35 PST
Date: 21 Mar 1988 1444-PST (Monday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc:
Subject: Re: statement to Congress on supercomputers
In-Reply-To: John McCarthy <JMC@sail.stanford.edu> /
21 Mar 88 1113 PST.
John,
Although I didn't indicate support for your initial statement, I am
somewhat concerned about lumping together the ERCs and the
Supercomputer centers. They are different. The ERCs support faculty and
students in the typical fashion, and they are not all that large (I'd
guess they average 2.5 M each). The supercomputer centers are all
facility and much more expensive. The biggest problem with the ERCs is
that scientific merit is not the deciding factor in awarding them.
John
∂21-Mar-88 1501 jlh@vsop.stanford.edu Re: statement to Congress on supercomputers
Received: from vsop.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:01:37 PST
Received: by vsop.stanford.edu; Mon, 21 Mar 88 14:59:17 PST
Date: 21 Mar 1988 1459-PST (Monday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc:
Subject: Re: statement to Congress on supercomputers
In-Reply-To: John McCarthy <JMC@sail.stanford.edu> /
21 Mar 88 1113 PST.
P.S. ERCs come out of the engineering directorate not the CS one.
∂21-Mar-88 1525 helen@Gang-of-Four.Stanford.EDU
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:25:18 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00728; Mon, 21 Mar 88 15:25:18 pst
Date: Mon, 21 Mar 88 15:25:18 pst
From: Helen Cunningham <helen@Gang-of-Four.Stanford.EDU>
Message-Id: <8803212325.AA00728@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Article 972 of rec.games.chess:
Path: labrea!agate!pasteur!ames!nrl-cmf!cmcl2!husc6!bbn!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!gxg
From: gxg@K.GP.CS.CMU.EDU (Gordon Goetsch)
Newsgroups: rec.games.chess
Subject: HITECH & National Open
Message-ID: <1183@PT.CS.CMU.EDU>
Date: 21 Mar 88 06:25:02 GMT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 43
Keywords: chess, computers
HITECH scored 5-1 in the recent National Open held this past weekend
in Chicago, tying for 7th place. HITECH's round by round results were :
Round 1 : HITECH (black) defeated Gregory Wichman (1988)
Round 2 : HITECH (black) defeated James Nielsen (2084)
Round 3 : HITECH (white) defeated William Breidenthal (2170)
Round 4 : HITECH (white) lost to GM Sergey Kudrin (2640, #10 in US)
Round 5 : HITECH (black) defeated Rafael Zafore (2145)
Round 6 : HITECH (white) defeated John Burke (2230)
Wichman declined an interesting opportunity early, and never got
another. Nielsen played a competitive game with HITECH till inaccuracies
near move 35 left him with an ever deteriorating position. HITECH quickly
took charge and was never in difficulty against Breidenthal. GM Kudrin built
up a devastating attack after an early sacrifice that HITECH was unable to
cope with. HITECH had a serious scare from Zafore, who outplayed it early
on, but he was unable to capitalize and lost. HITECH applied heavy pressure
early against Burke who was unable to cope. If HITECH had feelings, it might
hold a grudge against Kudrin who has now defeated it three times in as many
tries.
The Championship Section of the National Open had 380 entries.
There was a six-way tie for first with 5.5 points between : GM Mikhail Tal
(former world champion), GM Sergey Kudrin, FM Michael Brooks,
IM James Rizzitano, IM Calvin Blocker, and GM Leonid Shamkovich. Tied for
7th with 5 points were : NM HITECH, GM Maxim Dlugy, GM Walter Browne,
GM Bisguier, and possibly a few others.
HITECH's performance rating for this tournament was 2476 (estimated) and
its rating should rise from 2376 (estimated) to 2396 (estimated), a new high
water mark for computer chess. This tournament is HITECH's best performance
since tying for first in the Pennsylvania State Championship. Over its last
five tournaments, HITECH has achieved a performance rating of 2460.
From previous tournaments rated by FIDE, the international chess
federation, HITECH has achieved a performance worthy of a FIDE rating.
No computer has ever qualified for a FIDE rating. And now it appears that
no computer ever will. HITECH has met every qualification but one for
achieving a rating -- it is not a player (human). In a rules clarification,
FIDE has decided computers are not eligible for ratings, and titles. If
HITECH were eligible for a rating, it should have received a rating of
2350 on the January 88 FIDE Rating List.
∂21-Mar-88 1525 helen@Gang-of-Four.Stanford.EDU
Received: from Gang-of-Four.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:25:41 PST
Received: by Gang-of-Four.Stanford.EDU (4.30/25-eef)
id AA00739; Mon, 21 Mar 88 15:25:41 pst
Date: Mon, 21 Mar 88 15:25:41 pst
From: Helen Cunningham <helen@Gang-of-Four.Stanford.EDU>
Message-Id: <8803212325.AA00739@Gang-of-Four.Stanford.EDU>
To: jmc@sail
Article 975 of rec.games.chess:
Path: labrea!agate!ucbvax!decvax!purdue!sxr
From: sxr@cs.purdue.EDU (Saul Rosen)
Newsgroups: rec.games.chess
Subject: Re: HITECH & National Open
Message-ID: <3585@medusa.cs.purdue.edu>
Date: 21 Mar 88 17:49:05 GMT
References: <1183@PT.CS.CMU.EDU>
Sender: news@cs.purdue.EDU
Reply-To: sxr@arthur.cs.purdue.edu.UUCP (Saul Rosen)
Organization: Department of Computer Science, Purdue University
Lines: 12
Keywords: chess, computers
I don't mean to belittle Hitech's achievement in the National
Open, but as I read the results I see that Hitech won from four
experts and from one weak master. It lost to the only really
strong player it played. I don't see why this record should
increase its rating still higher in the 2300-2400 range. I suppse
it has something to do with the very high rating of the player to
whom it lost.
Of course the real problem here lies in the fact that six rounds
is not enough to determine the winners in a tournament with
this many players. I hope that in the future they will be able
to schedule eight rounds to make the results more meaningful.
∂21-Mar-88 1528 REIS@Sierra.Stanford.EDU Re: title and abstract
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:28:32 PST
Date: Mon 21 Mar 88 15:28:49-PST
From: Rick Reis <REIS@Sierra.Stanford.EDU>
Subject: Re: title and abstract
To: JMC@Sail.Stanford.EDU
cc: reis@Sierra.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 21 Mar 88 14:29:00-PST
Message-ID: <12384201170.12.REIS@Sierra.Stanford.EDU>
Thank's John:
I think I've got what I need to put a flyer together. Can you tell
me what your audio-visual needs will be. We will be in the
Terman Auditorium and your presentation will be video taped but do
you want to use overheads, slides, etc. Just let me know when you
get a chance and otherwise I'll check with you in a couple of
weeksCheers
Rick
-------
∂21-Mar-88 1537 REIS@Sierra.Stanford.EDU re: title and abstract
Received: from Sierra.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:37:36 PST
Date: Mon 21 Mar 88 15:37:56-PST
From: Rick Reis <REIS@Sierra.Stanford.EDU>
Subject: re: title and abstract
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 21 Mar 88 15:36:00-PST
Message-ID: <12384202831.12.REIS@Sierra.Stanford.EDU>
Yes, April 15th at noon.
Rick
-------
∂21-Mar-88 1823 FEIGENBAUM@SUMEX-AIM.Stanford.EDU statement
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 18:23:49 PST
Date: Mon, 21 Mar 88 18:18:04 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: statement
To: jmc@sail.Stanford.EDU
cc: feigenbaum@SUMEX-AIM.Stanford.EDU
Message-ID: <12384231982.78.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
John, the actual statement came across as overly strong. In fact, it
attacked just the kind of thing I do: to wit, running a big laboratory.
I thought you were going to attack supercomputing centers specifically.
Supercomputer funding is funding for big cycle users, as oposed to funding
for CS research. I don't want to make the attack on small vs big, because
some big stuff is very good, e.g. Newell's big project on SOAR or
Reddy's big speech and robotics projects.
Gabriel's comments were well-taken.
Ed
-------
∂21-Mar-88 2242 FEIGENBAUM@SUMEX-AIM.Stanford.EDU party
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 22:42:16 PST
Date: Mon, 21 Mar 88 22:43:54 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: party
To: jmc@sail.Stanford.EDU, clt@sail.Stanford.EDU
Message-ID: <12384280375.28.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Dear Carolyn and John,
We are having a party on April 5,our thirteenth wedding
anniversary. We hope you can come to help us celebrate.
It's a sushi dinner, followed by an evening of theater.
The theater event is a Palo Alto Theaterworks production of
Sondheim's musical Pacific Overtures. It starts at 8PM.
Before that, starting at 6PM, is a sushi dinner at Tsuruya
Sushi, 151 California Avenue (across the street from COOP).
Dinner will be over about 7:20, to allow time to drive over
to the Embarcadero-and-Newell area (Lucy Stern Community
Center area) where the theater is.
We'll have the theater tickets at the restaurant, but if you
can't come to the dinner, let us know so that we can get the
tickets to you some other way.
RSVP to Sue Irvine at 723-4878 or to us at home, 493-5618,
so that we have a good ticket and sushi count! (E-mail is OK
too).
Looking forward to seeing you,
Penny Nii and Ed Feigenbaum
-------
∂22-Mar-88 0324 SOSTOYAN%DKNKURZ1.BITNET@forsythe.stanford.edu mail test
Received: from lindy.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Mar 88 03:24:00 PST
Received: by lindy.stanford.edu; Tue, 22 Mar 88 03:24:08 PST
From: SOSTOYAN%DKNKURZ1.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Tue, 22 Mar 88 03:23:19 PST
Date: Tue, 22 Mar 88 10:56:40 MEZ
To: JMC@sail.stanford.edu
Comment: CROSSNET mail via MAILER@STANFORD
Return-Receipt-To: SOSTOYAN@dknkurz1.bitnet
Subject: mail test
Date: 22 March 1988, 10:54:30 MEZ
From: Herbert Stoyan +49 7531 88 3593 SOSTOYAN at DKNKURZ1
To: John McCarthy JMC at SAIL
Hi John. How are you? Did you get my mail? What's your position about
the anniversary now? Bye. Herbert
∂22-Mar-88 0629 AI.BRANTON@R20.UTEXAS.EDU Retirement Refund
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 06:29:09 PST
Date: Tue 22 Mar 88 08:29:50-CST
From: AI.BRANTON@R20.UTEXAS.EDU
Subject: Retirement Refund
To: mccarthy@SAIL.STANFORD.EDU
cc: AI.BRANTON@R20.UTEXAS.EDU
Message-ID: <12384365196.31.AI.BRANTON@R20.UTEXAS.EDU>
Dr. McCarthy:
Did you receive the forms I mailed to you to try to reclaim your
Teacher's Retirement money? If so, did it work?
Thanks.
Suezette
-------
∂22-Mar-88 1037 CLT house
the architect is coming today at 3:45 to look at our
house. we will go look at the San Juan house at 4:30.
You could just meet us at the San Juan place if you
get a chance.
∂22-Mar-88 1238 MPS Expenses
I talked to Betty Scott about your expenses. She said
that without receipts for a large amount, you probably
will not be aale to get paid.
Her suggestion was, is that you try to get duplicates of
the major receipts, i.e. airfare, hotels, etc.
Pat
∂22-Mar-88 1550 BMOORE@Warbucks.AI.SRI.COM Re: a puzzle about introspection
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 22 Mar 88 15:50:08 PST
Date: Tue 22 Mar 88 15:46:00-PST
From: BMOORE@Warbucks.AI.SRI.COM (Bob Moore)
Subject: Re: a puzzle about introspection
To: perlis@YOOHOO.CS.UMD.EDU
cc: BMOORE@KL.SRI.COM, CGS.KAMP@R20.UTEXAS.EDU, THOMASON@C.CS.CMU.EDU,
jmc@SAIL.STANFORD.EDU, konolige@KL.SRI.COM, loui@CS.ROCHESTER.EDU,
reiter%utai.toronto.edu@RELAY.CS.NET, sjg@SAIL.STANFORD.EDU,
utai!reiter@UUNET.UU.NET, val@SAIL.STANFORD.EDU,
CGS.ASHER@R20.UTEXAS.EDU, JEEM%TORONTO.CSNET@RELAY.CS.NET,
PHAYES@KL.SRI.COM, ether%allegra.att.com@RELAY.CS.NET,
fagin%almvma.bitnet@WISCVM.WISC.EDU, fagin@IBM.COM,
grosof@SAIL.STANFORD.EDU, halpern%almvma.bitnet@WISCVM.WISC.EDU,
halpern@IBM.COM, hector%utai.toronto.edu@RELAY.CS.NET,
hector%toronto.csnet@RELAY.CS.NET, jbarnden%nmsu@RELAY.CS.NET,
phayes@sri-kl.arpa, shoham@YALE.ARPA, BMOORE@Warbucks.AI.SRI.COM
Message-ID: <575077561.0.BMOORE@WARBUCKS.AI.SRI.COM>
In-Reply-To: <8803110019.AA07636@yoohoo.cs.umd.edu>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
Don,
There is no contradiction implied by the example that you give. The
reason is that K is interpreted with respect to a complete set of
beliefs, including default inferences. Hence -K-B is not in any
stable expansions, extensions, etc. This is true both for my logic,
and all the others I know of for which the analogous question arises.
--Bob
-------
∂22-Mar-88 1955 GLB
∂22-Mar-88 1950 JMC
I'll look at your thesis proposal with a view to joining the committee.
-------
That would be great, thank you! If you want, whenever it's convenient for you,
I'll answer questions.
∂23-Mar-88 1000 JMC
Simpson
∂23-Mar-88 1024 GINSBERG@Sushi.Stanford.EDU formfeed meets tomorrow
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:24:08 PST
Date: Wed 23 Mar 88 09:16:58-PST
From: Matthew L. Ginsberg <GINSBERG@Sushi.Stanford.EDU>
Subject: formfeed meets tomorrow
To: feed@Sushi.Stanford.EDU
Message-ID: <12384657767.10.GINSBERG@Sushi.Stanford.EDU>
12.00, as usual; we'll be back in MJH 252. Also, I'll be away next
week -- could people please send me their new addresses (those on
SUSHI, at least) so that I can keep the mailing list current?
Thanks.
Matt
-------
∂23-Mar-88 1117 SLOAN@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:16:43 PST
Date: Wed 23 Mar 88 11:12:14-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Tue 22 Mar 88 19:49:00-PST
Message-ID: <12384678750.29.SLOAN@Score.Stanford.EDU>
Professor McCarthy,
Ketonen's appointment papers have been signed by the Dean's Office and are now
in the Provost's Office waiting for approval. Rose Ewing in the Dean's Office
did not expect any problems with his appointment so we should know something
by tomorrow.
--Yvette
-------
∂23-Mar-88 2041 perlis@yoohoo.cs.umd.edu Re: a puzzle about introspection
Received: from gyre.umd.edu by SAIL.Stanford.EDU with TCP; 23 Mar 88 20:41:35 PST
Received: from yoohoo.cs.umd.edu by gyre.umd.edu (5.58/4.7)
id AA12262; Wed, 23 Mar 88 23:39:52 EST
Received: from localhost by yoohoo.cs.umd.edu (5.54/3.14)
id AA19277; Wed, 23 Mar 88 23:40:10 EST
Return-Path: <perlis@yoohoo.cs.umd.edu>
Message-Id: <8803240440.AA19277@yoohoo.cs.umd.edu>
To: bmoore@kl.sri.com, cgs.kamp@r20.utexas.edu, thomason@c.cs.cmu.edu,
jmc@sail.stanford.edu, konolige@kl.sri.com, loui@cs.rochester.edu,
reiter%utai.toronto.edu@relay.cs.net, sjg@sail.stanford.edu,
utai!reiter@uunet.uu.net, val@sail.stanford.edu,
cgs.asher@r20.utexas.edu, jeem%toronto.csnet@relay.cs.net,
phayes@kl.sri.com, ether%allegra.att.com@relay.cs.net,
grosof@sail.stanford.edu, hector%utai.toronto.edu@relay.cs.net,
hector%toronto.csnet@relay.cs.net, jbarnden%nmsu@relay.cs.net,
phayes@sri-kl.arpa, shoham@yale.arpa, vardi@gyre.umd.edu
Cc: perlis@yoohoo.cs.umd.edu
Subject: Re: a puzzle about introspection
In-Reply-To: Your message of Tue 22 Mar 88 15:46:00-PST.
<575077561.0.BMOORE@WARBUCKS.AI.SRI.COM>
Date: Wed, 23 Mar 88 23:40:06 -0500
From: Don Perlis <perlis@yoohoo.cs.umd.edu>
Many of you replied to the effect that existing formalisms (such as AE
logic) do not yield the -K-B result that my claims rest on. This is quite
true. I was not suggesting an internal problem in existing formalisms but
rather pointing out that -K-B is indeed part of what reasoning *ought* to
involve. Let me offer then a clarification of this point:
When we follow Moore's example of the brother, the apparent force to the
axiom B -> KB is that "if you had a brother you would *already* know it"
since it would be such a basic observation, part and parcel of your life.
If you had to figure it out, then essential information could easily have
failed to be available to you, and this is not what the force of the example
relies on. Yet this is *not* what many formalisms have in fact formalized.
My earlier message had to do with what happens if we do go ahead and deal
with reasoning based on conclusions as to what we do not *already* know.
But it is clearly true then that also -K-B holds on this *already* known
interpretaton, in any case in which -KB -> -B is actually *used* for
anything (since otherwise K-B and -B would be concluded anyway without the
AE axiom).
----
Don Perlis (301) 454-7931
perlis@mimsy.umd.edu
seismo!mimsy!perlis
Computer Science Department
University of Maryland
College Park, MD 20742
∂24-Mar-88 1102 perlis@yoohoo.cs.umd.edu original problem
Received: from gyre.umd.edu by SAIL.Stanford.EDU with TCP; 24 Mar 88 11:02:38 PST
Received: from yoohoo.cs.umd.edu by gyre.umd.edu (5.58/4.7)
id AA16000; Thu, 24 Mar 88 14:02:25 EST
Received: by yoohoo.cs.umd.edu (5.54/3.14)
id AA19848; Thu, 24 Mar 88 14:02:41 EST
Date: Thu, 24 Mar 88 14:02:41 EST
From: perlis@yoohoo.cs.umd.edu (Don Perlis)
Return-Path: <perlis@yoohoo.cs.umd.edu>
Message-Id: <8803241902.AA19848@yoohoo.cs.umd.edu>
To: jmc@sail.stanford.edu
Subject: original problem
John: Here is the original problem --
Subject: a puzzle about introspection
I recently noticed an odd thing regarding negative introspection, which I
regard as the basis for default reasoning. Namely, if we conclude C on the
basis of A and of not knowing B:
A and -KB .-->. C
then the following situation can arise. Consider the simple example due to
Moore, where B is the proposition `I have an elder brother' and C is -B.
Specifically, we have
-KB --> -B
that is, not knowing one has an elder brother entails not having one.
Now, if the reasoner is given information which, taken together, indeed does
not entail B, and if it has an introspection-oracle so that it can infer
this fact, -KB, then modus ponens does the rest, giving -B.
Note that if the reasoner's information entails -B directly (without the use
of the introspection-oracle) then there is no need to invoke it, although
doing so is harmless enough. Moreover, the force of Moore's approach, like
that of most examples of non-monotonic reasoning, is to derive a result that
was not otherwise available. That is, the point of such reasoning is to aid
in deciding undecided cases, in which it is not known whether or not B is
true. For if either B or -B is already known then the issue is moot.
On the other hand, if neither B nor -B is so entailed, then the reasoner
cannot decide either -B or B without a default mechanism, which in turn
involves an introspection-oracle. Thus the indeterminate status of B is
what makes the oracle important for allowing a default conclusion. Yet in
precisely this case, not only do we have -KB but also -K-B! So the reasoner
knows neither -B nor B. But it should then come to realize this, i.e.,
realize the fact of indeterminacy: -KB and -K-B, rather than simply -KB.
Yet, on that basis, it is led to conclude -B after all! The result is that
both -B and -K-B are concluded by the reasoner! Thus there is (almost) an
inconsistency, which becomes blatant if there is also a positive
introspection-oracle to derive K-B from -B.
Now there is an obvious sense in which this can be explained: time has
passed between the (early) fact of -K-B and then later fact of -B's being
concluded, so that -K-B is no longer true once -B is concluded. But this
then calls for a very different analysis of default reasoning, it seems to
me. No longer is there the idealization of a fixed theory closed under
inferential operations.
As far as I can see, this bodes ill for formalizations of default reasoning
in single-theory frameworks. I would be interested in your reactions.
-Don
∂24-Mar-88 1123 ULLMAN@Score.Stanford.EDU Re: statement to Congress on supercomputers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 11:23:29 PST
Date: Thu 24 Mar 88 11:18:59-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: Re: statement to Congress on supercomputers
To: JMC@Sail.Stanford.EDU
In-Reply-To: Message from "John McCarthy <JMC@SAIL.Stanford.EDU>" of Mon 21 Mar 88 11:13:00-PST
Message-ID: <12384942122.27.ULLMAN@Score.Stanford.EDU>
Very nicely put. I am happy to endorse your statement.
---jdu
-------
∂24-Mar-88 1503 JSW Hertz luncheon
I've called Hertz to have them reserve a seat for you at tomorrow's
luncheon. It is at 11:45 at Hyatt Rickey's.
∂24-Mar-88 2201 beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU triangles
Received: from ucscd.UCSC.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 22:01:06 PST
Received: by ucscd.UCSC.EDU (5.57/1.1)
id AA01048; Thu, 24 Mar 88 22:02:33 PST
Date: Thu, 24 Mar 88 22:02:33 PST
From: beeson%ucscd.UCSC.EDU@ucscc.UCSC.EDU (20012000)
Message-Id: <8803250602.AA01048@ucscd.UCSC.EDU>
To: jmc@sail.stanford.edu
Subject: triangles
I wanted to show that the isosceles triangle of base 2 and height sqrt(7)
is not embeddable in Z↑4 either (we know it is in Z↑5 and is not in Z↑3).
I made the C program to check for solutions mod n as efficient as I
could and tried it for various n. The only one that didn't have a solution
right away was n=32. I ran it for three hours, long enough to see that
it would take about 12 days to finish if indeed there is no solution.
Guess I'll have to look for a faster computer. (This was on my 6 mhz AT).
Could probably double the speed using assembly language for Euclid's
algorithm instead of C, because there you can get quotient and remainder
in one step instead of two.